← 200 messages moved from Raiders of the Lost Downboat

So, do you think sudo -E not using the user's PATH is the intended behaviour, only seemingly not well documented and somewhat counterintuitive?

@Zanna Does turning off secure_path make -E use the user's path (i.e., pass the PATH through)?

turning off secure_path causes the user's path to be used, without -E

Even if env_reset is enabled in sudoers?

yes.

Is that because this passage, from sudoers(5), is meant to be interpreted as saying that PATH is passed through even with env_reset?

 By default, the env_reset option is enabled.  This causes commands to be
 executed with a new, minimal environment.  On AIX (and Linux systems
 without PAM), the environment is initialized with the contents of the
 /etc/environment file.  The new environment contains the TERM, PATH,
 HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables in addi‐
 tion to variables from the invoking process permitted by the env_check
 and env_keep options.  This is effectively a whitelist for environment

I'm not sure how to interpret that.

yeah I'm not sure, but I think that (and other bits that say similar things) are saying that the effect of env_reset is to cause sudo to inherit only those variables?

I don't know. Is the "The new environment contains" part also about what happens on AIX and "Linux systems without PAM" (which wouldn't include Ubuntu)?

ek@Io:~$ SHELL=FOOBAR sudo printenv SHELL
/bin/bash

ek@Io:~$ MAIL=abcdefg sudo printenv MAIL
/var/mail/root

hmmm...

That's with the default options in /etc/sudoers.

zanna@toaster:~$ printenv MAIL
zanna@toaster:~$ sudo printenv MAIL
/var/mail/root

well it is doing something

I don't have a lot of faith in the sudo documentation. There are multiple interpretations that could be assigned to numerous parts of the manpages. Also, sudoers(5) is notorious for exemplifying the "hard to read" tradition of manpages by attempting to teach the reader EBNF in order to then use it to describe the syntax of sudoers files.

I had great difficulty in understanding how to add things to sudoers files from man sudoers haha

I think this (quoted before, but again for convenience) is the key... whatever it means:

 secure_path   Path used for every command run from sudo.  If you don't
               trust the people running sudo to have a sane PATH environ‐
               ment variable you may want to use this.  Another use is if
               you want to have the “root path” be separate from the “user
               path”.  Users in the group specified by the exempt_group
               option are not affected by secure_path.  This option is not
               set by default.

[From sudoers(5).]

It doesn't say the value of secure_path is used as the value of the PATH environment variable for every command run from sudo. It says the value of secure_path is the "[p]ath used for every command run from sudo." That's extremely ambiguous, but it could mean that it is the value used to look up every command that sudo looks up. If it means that, then this is a straight-up bug in the documentation, though, because not every command you run with sudo causes path lookup to occur.

(Because you can write things like sudo /bin/nano.)

I think that it should be possible to test which meaning is intended by setting the exempt_group option, referred to in the passage I quoted above, which is documented as:

 exempt_group  Users in this group are exempt from password and PATH
               requirements.  The group name specified should not include
               a % prefix.  This is not set by default.

I have just tested this. Before adding the exempt_group option to sudoers, I did this:

ek@Io:~$ useless
useless: command not found
ek@Io:~$ PATH="$PATH:$HOME/junk" useless
foo
ek@Io:~$ PATH="$PATH:$HOME/junk" sudo useless
sudo: useless: command not found
ek@Io:~$ sudo PATH="$PATH:$HOME/junk" useless
sudo: useless: command not found

I had these usual Defaults lines in /etc/sudoers:

Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Then I used visudo to edit the file and add this line, which works because ek is the name of my user's primary group (my username is ek but that is not why it works):

Defaults    exempt_group="ek"

...

I logged in again, by just SSHing to localhost, to be sure it would take effect (but subsequent testing revealed that, as I had expected, this is not necessary). I can run commands with sudo without a password, and sudo -k does not prevent me from doing so; nor does sudo -K. I take this to mean that the setting took effect.

Now that exempt_group covers me (and, in case it turns out somehow to matter, this is in the shell obtained by SSHing to localhost), it works differently:

ek@Io:~$ useless
useless: command not found
ek@Io:~$ PATH="$PATH:$HOME/junk" useless
foo
ek@Io:~$ PATH="$PATH:$HOME/junk" sudo useless
foo
ek@Io:~$ sudo PATH="$PATH:$HOME/junk" useless
sudo: useless: command not found

hmm!

By just changing exempt_group and nothing else, the PATH that sudo inherits from the calling environment is automatically used for path lookup. It is also passed through to commands:

ek@Io:~$ sudo printenv PATH
/home/ek/perl5/bin:/home/ek/.gem/ruby/2.3.0/bin:/home/ek/.local/bin:/home/ek/bin:/home/ek/.sdkman/candidates/kotlin/current/bin:/home/ek/perl5/perlbrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

So this is sudo using the PATH it inherits from the calling environment:

ek@Io:~$ PATH="$PATH:$HOME/junk" sudo useless
foo

However, sudo still doesn't have a VAR=value pair passed as a command-line argument affect its own path lookup:

ek@Io:~$ sudo PATH="$PATH:$HOME/junk" useless
sudo: useless: command not found

I get the same results when I disable secure_path

I think that answer is just wrong, then, in saying that you can use commands like sudo PATH="$PATH" godi_console.

maybe that works in some environments, for some reason?

Depending on the version of sudo?

calls visudo again before sudo times out

yeah

Does this comment make sense?

yes

but what is going on? :)

@Zanna Speaking of my comments that might or might not make sense... had you mentioned whether nor that comment was clear? Because it is very far from obvious to me that it is.

Our conversation about it did not increase my confidence in that comment, because it made me realize that it is not immediately obvious what it means for a command name to be "interpreted as a path," given that filenames other than / (the filename for the directory whose full path is /) are themselves kinds of relative paths, and external commands that are not (in the sense I mean) interpreted as paths are nonetheless looked up in a manner that treats them as filenames.

*are themselves a kind of relative path

@EliahKagan sorry, I did not comment as to whether it was clear because I first wanted to understand why it was important that it be interpreted as a path. Now that is very clear to me. I think it is clear from your comment that / in the command causes it to be interpreted as a path

Might there be a better way for me to say it, though?

@Zanna Did you end up deciding to keep the wording as it was?

no, I forgot about it :(

@Zanna I don't want to lessen your focus on Tamil, so I am not saying you should do this, especially if it would have that result. But did you ever decide to pursue Ruby? I'm asking because I have some thoughts about that -- about Ruby, I mean, rather than about other languages that I thought might interest you, which I already talked about -- but I am not sure what you've decided (not that any decision would have to be final anyway!) about learning Ruby.

@Zanna I have edited it now :)

thanks for reminding me!

You're welcome. :)

I can't say I have made a decision about learning Ruby or any other language as of now. I have not arrived haha

what you said about why resource-efficiency of code matters was the most influential thing you have said about that topic so far

This question could use another answer explaining what is actually going wrong, but I have to go afk. I can write such an answer eventually but if anybody else wants to I would be grateful. :)

@EliahKagan I love how dobey has written "the correct incantation..."

Yeah, that's a thing people say about *nix commands especially. :)

The thing is, the existing answer really doesn't explain the OP's mistake at all, and it's not obvious to me that it is actually correct, though it may be, and either way its advice is good. I wish the OP had shown the output of their g++ and c++ invocations or stated explicitly that they were silent.

It seems unlikely that it did actually compile without the source code file having a suffix recognized by the compiler or an option passed to the compiler to tell it what language was being compiled (contrary to popular assumption, just because you use g++ or c++ as the compiler drive doesn't mean the compiler assumes C++).

But the output is consistent with the possibility that it did compile silently, emitted an executable as a.out, and then the OP ran their source code file as a shell script.

So anyway if you or anyone feels like double-checking that my "they ran their source code as a shell script" hypothesis is consistent with all the facts and then writing an answer, please do very much feel free.

I don't know how to answer the question... it's obvious from their error messages what is happening :) but I am not sure about what they did... they ran the compiler, possibly, and it perhaps did something, but OP has then tried to run the source file

oh sorry... lagging

@EliahKagan Although I don't actually disagree with the downvotes there, I guess, people don't usually downvote questions of that quality. I think people see C++ and assume a question is off-topic or whatnot. If they had shown their code I would have upvoted that question. Alas.

yeah, the question could be quite useful

Oh. I guess people downvoted because not only did the OP not include the code, but it's impractical to go look (if that is, in fact, the site they used).

o.O

Well I've commented.

thanks :)

@EliahKagan *g++ or c++ as the compiler driver (not drive)