setting path for root after "sudo su" and "sudo" for Debian Bullseye (11)

[Tom Browder]

I need a special path setting for root after both "sudo" and "sudo su." How can I set that up correctly?

Searching for a definitive answer seems hopeless. Any working solution is greatly appreciated.

In desperation I've thought about modifying /etc/login.defs for both root and all users, but hope there is a better solution.

Best regards,

-Tom

[Greg Wooledge]

On Wed, May 18, 2022 at 09:36:56PM -0500, Tom Browder wrote:
> I need a special path setting for root after both "sudo" and "sudo su." How
> can I set that up correctly?

Let's start by pointing out how silly the latter is. You're running TWO
different setuid programs, either one of which is capable of giving
you a root shell by itself.

If you want to use sudo to open an interactive shell as root, simply
use "sudo -s" for a normal shell, or "sudo -i" for a login shell.

So, moving on. sudo on Debian sets the PATH variable by default (because
it wasn't tainted by idiocy like su was in buster). This is controlled
by the following entry in the /etc/sudoers file:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

And just to confirm:

unicorn:~$ sudo -s
unicorn:~# echo "$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Pretty simple, right? If you want a different path from sudo, you can
simply edit that entry in the sudoers file. (Purists will tell you to
use "visudo" to do it.)

Now, what's the deal with su?

In Debian releases from 1.1 to 9, the "su" program was provided by the
"login" package, and it always changed the PATH variable. regardless of
whether you used it to get a normal shell ("su") or a login shell ("su -").

In Debian 10 and 11, the "su" program is provided by the "util-linux"
package, and comes from a completely different code base. The default
behavior of this version is NOT to set the PATH variable. So, if you
simply do "su", you get a root shell with your regular account's PATH.

A bunch of people are apparently used to this, because Red Hat has used
it for a long time. And also apparently, the workaround that the Red Hat
community has embraced is to run "su -" to get a login shell, and then
rely on the *shell* to change the PATH variable for you, based on either
/etc/profile or root's ~/.profile.

A much better workaround is to create the /etc/default/su file and put
the line

ALWAYS_SET_PATH yes

in it. This will tell "su" to change the PATH variable to something
sensible, without you needing to run "su -" to get a login shell which
changes your working directory. It's a reasonable approximation of
the traditional Debian behavior, and it can be achieved by creating
a one-line configuration file.

I strongly believe that the Debian developers should have shipped this
file with util-linux in Debian 10+, but sadly, they did not.

If you want to customize the PATH that you get from su (after putting
ALWAYS_SET_PATH in the config file), you can add another line. Here's
the relevant section of the su(1) man page from bullseye:

ENV_ROOTPATH (string)
ENV_SUPATH (string)
Defines the PATH environment variable for root. ENV_SUPATH takes
precedence. The default value is /usr/local/sbin:/usr/local/bin:
/sbin:/bin:/usr/sbin:/usr/bin.

ALWAYS_SET_PATH (boolean)
If set to yes and --login and --preserve-environment were not spec‐
ified su initializes PATH.

So, still pretty simple. You just have to read the documentation and
write the (two-line) config file yourself, since Debian didn't bother
to do it.

[황병희]

Tom Browder <tom.b...@gmail.com> writes:

> I need a special path setting for root after both "sudo" and "sudo

> su." (...)

Just you try like as "sudo su -". Sometimes i use it that way.

Sincerely, Linux fan Byung-Hee

--
^고맙습니다 _白衣從軍_ 감사합니다_^))//

[Kamil Jońca]

Tom Browder <tom.b...@gmail.com> writes:

> I need a special path setting for root after both "sudo" and "sudo su." How can I set that up correctly?

It is quite misterious for me.
What is the purpose of "sudo su" instead of plain "sudo" or "sudo -i"
KJ

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

[Tom Browder]

On Thu, May 19, 2022 at 03:54 Kamil Jońca <kjo...@o2.pl> wrote:

Tom Browder <tom.b...@gmail.com> writes:

> I need a special path setting for root after both "sudo" and "sudo su." How can I set that up correctly?

It is quite misterious for me.
What is the purpose of "sudo su" instead of plain "sudo" or "sudo -i"

KJ, and others, let me describe my specific use case:

As a normal user, I have developed a single script written in Raku (https://raku.org) that does a lot of work to collect all requirements to build and install the latest OpenSSL and Apache2 httpd. The install step requires:

    $ sudo ./myprog install

or

    $ sudo su

    # ./myprog install

The "myprog" program has a shebang line that requires a path to the pertinent Raku executables. That line looks like this:

    #!/usr/bin/env raku

I have for years now not used the many variants of su, just "sudo" alone for one-off use and "sudo su" when I'm doing several things as root. That serves me well for most everything I do on Debian.

I am not a full-time sysadmin, so I don't spend a lot of time with the hard details--I try to simplify things as much as I reasonably can.

Thanks.

-Tom

P.S. You Perl people should seriously investigate Raku--it's a better Perl, Perl on steriods!

[Greg Wooledge]

On Thu, May 19, 2022 at 05:47:29AM -0500, Tom Browder wrote:
> $ sudo su
> # ./myprog install

Again, there's no reason to use both "sudo" AND "su". Just "sudo -s"
would give you the interactive root shell, without changing directory.

I feel like you're doing "sudo su" out of some bad habit that you've
developed. You'd be doing yourself a favor if you retrain yourself
to use "sudo -s" instead.

[Tom Browder]

Greg, I think I need to change the paths in the sudoer file. I just tried the "sudo -i" and sudo -s" incantations on my script and they still don't have the needed path component.

I use the "/etc/sudoers.d" directory with my "username-sudoer" file under it. Is that file a place where I could affect the path with some kind of bashism?

-Tom

[Greg Wooledge]

On Thu, May 19, 2022 at 06:22:07AM -0500, Tom Browder wrote:
> On Thu, May 19, 2022 at 06:03 Greg Wooledge <gr...@wooledge.org> wrote:
>
> > On Thu, May 19, 2022 at 05:47:29AM -0500, Tom Browder wrote:
> > > $ sudo su
> > > # ./myprog install
> >
> > Again, there's no reason to use both "sudo" AND "su". Just "sudo -s"
> > would give you the interactive root shell, without changing directory.
> >
> > I feel like you're doing "sudo su" out of some bad habit that you've
> > developed. You'd be doing yourself a favor if you retrain yourself
> > to use "sudo -s" instead.
>
>
> Greg, I think I need to change the paths in the sudoer file. I just tried
> the "sudo -i" and sudo -s" incantations on my script and they still don't
> have the needed path component.

Which is... what?

Perhaps what you should be doing instead is creating a symlink named
/usr/local/bin/raku which points to your /opt/whatever/raku program.
That's how third-party (or local) programs that don't install in
/usr/local are typically handled.

> I use the "/etc/sudoers.d" directory with my "username-sudoer" file under
> it. Is that file a place where I could affect the path with some kind of
> bashism?

No idea. Try it and see? Also, I'm not sure what you mean by "bashism"
here, but good luck trying to decipher the sudoers(5) man page to see
what's allowed and what isn't.

[Tom Browder]

On Thu, May 19, 2022 at 06:31 Greg Wooledge <gr...@wooledge.org> wrote:

...

> > I feel like you're doing "sudo su" out of some bad habit that you've
> > developed.  You'd be doing yourself a favor if you retrain yourself
> > to use "sudo -s" instead.
>
> Greg, I think I need to change the paths in the sudoer file. I just tried
> the "sudo -i" and sudo -s" incantations on my script and they still don't
> have the needed path component.

Which is... what?

Perhaps what you should be doing instead is creating a symlink named
/usr/local/bin/raku which points to your /opt/whatever/raku program.
That's how third-party (or local) programs that don't install in
/usr/local are typically handled.

Hm, I'll think about that. It's a good question for the man who maintains the third party Debian package for Raku. 

> I use the "/etc/sudoers.d" directory with my "username-sudoer" file under
> it. Is that file a place where I could affect the path with some kind of
> bashism?

No idea.  Try it and see?  Also, I'm not sure what you mean by "bashism"
here, but good luck trying to decipher the sudoers(5) man page to see
what's allowed and what isn't.

Yes, that was part of my reference to doc confusion in the original post.

"bashism" is my snarky reference to my favorite shell (ugh, I used to love cshell for some dumb reason, oh yeah, it was the default shell on Sun OS and SGI Irix back in the day).

Thanks for good ideas, Greg.

-Tom

[Nicholas Geovanis]

On Thu, May 19, 2022, 3:14 AM 황병희 <soye...@doraji.xyz> wrote:

Tom Browder <tom.b...@gmail.com> writes:

> I need a special path setting for root after both "sudo" and "sudo
> su." (...)

Just you try like as "sudo su -". Sometimes i use it that way.

When I need to use sudo or su to invoke executables, I fully qualify the path to sudo and the path to that specific executable by using their full path from /. And I often assign values to the important environment variables at the beginning of that same command line. Like...

joe="schmoe" slap="moe" /usr/bin/sudo ....

The idea is to draw a line around that invocation by limiting what it "knows".

[Kenneth Parker]

When I need Root on a Desktop, I bring up a shell, enter "su -" and give it the Root Password. 

Note, Debian (at least in the Expert Installation Mode) lets me set a Root Password.   Ubuntu doesn't, so one of my early actions after the Install is to enter "sudo su -" and, on the resulting Root Shell, type "passwd root".

On a Virtual Terminal, I simply login as Root on one terminal, and on the next one, sign on as my "Normal User" (and then do most of my work there).

I know there have been Discussions here about sudo vs "su -". They both work, but both can get you in trouble (but possibly in different ways).

Kenneth Parker 

Kenneth Parker 

[Timothy M Butterworth]

On Thu, May 19, 2022 at 8:25 PM Kenneth Parker <sea7...@gmail.com> wrote:

On Thu, May 19, 2022, 4:14 AM 황병희 <soye...@doraji.xyz> wrote:

Tom Browder <tom.b...@gmail.com> writes:

> I need a special path setting for root after both "sudo" and "sudo
> su." (...)

You do not need to use sudo with su. When you enter su you are prompted to enter the root password. 

[Brian]

On Thu 19 May 2022 at 20:24:50 -0400, Kenneth Parker wrote:

[...]

> Note, Debian (at least in the Expert Installation Mode) lets me set a Root
> Password. Ubuntu doesn't, so one of my early actions after the Install is
> to enter "sudo su -" and, on the resulting Root Shell, type "passwd root".

Depends on whta you mean by "Ubuntu". Its mini.iso offers settong a root
password. I wonder whether the regular ISO can be preseeded?

--
Brian.

[David Wright]

If you're running bash, then giving the full path for sudo will
circumvent any aliases you've defined, and any other versions
of sudo available from earlier in your $PATH, but there's not
necessarily any security bonus. After Greg (2018):

$ function /usr/bin/sudo { echo teehee; }
$ /usr/bin/sudo whatever
teehee
$

Cheers,
David.

[Nicholas Geovanis]

Translation: There is no silver bullet that makes your system secure. There are many steps large and small that make it incrementally more secure. Yes that's true.

[The Wanderer]

A quick test demonstrates that this can be worked around via the 'unset'
command:


$ type malicious
bash: type: malicious: not found
$ function malicious { echo "Not really, but..."; }
$ type malicious
malicious is a function
malicious ()
{
echo "Not really, but..."
}
$ unset malicious
$ type malicious
bash: type: malicious: not found


It might look as if this could mean you could work around many possible
cases of malice by just issuing 'unset [command-name]' before any
command you're concerned about, but unfortunately, this same process can
be used to override 'unset' itself; I'm not going to reproduce the exact
commands and output here (mostly because I already closed that window
and I don't want to run through it all again), but a malicious actor
could just override 'unset' to something malicious and then you might
have no way of getting out of it within the running session.

(Such an actor could also override 'type' and 'set' and so forth to
something that would report the expected values, so even detecting that
this had been done could be difficult. Writing a shell function that
would behave "correctly" in that role could be difficult, and I
certainly don't intend to try to do it, but I don't think it would be at
all impossible.)

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Greg Wooledge]

On Fri, May 20, 2022 at 08:41:43PM -0400, The Wanderer wrote:
> On 2022-05-20 at 20:28, David Wright wrote:
> > $ function /usr/bin/sudo { echo teehee; }
> > $ /usr/bin/sudo whatever
> > teehee
> > $
>
> A quick test demonstrates that this can be worked around via the 'unset'
> command:

Until you define a function named unset.

But the real point here is that you should only use sudo or su (or doas
or any other program that reads your password) from a trusted environment.
What you definitely should NOT do is get called by a coworker, go over to
their workstation, hear the description of a problem, and try to fix it
from their computer, where they may have overridden su/sudo/etc.

Go back to your own desk first, and fix it from there.

[The Wanderer]

On 2022-05-20 at 21:20, Greg Wooledge wrote:

> On Fri, May 20, 2022 at 08:41:43PM -0400, The Wanderer wrote:
>
>> On 2022-05-20 at 20:28, David Wright wrote:
>>
>> > $ function /usr/bin/sudo { echo teehee; }
>> > $ /usr/bin/sudo whatever
>> > teehee
>> > $
>>
>> A quick test demonstrates that this can be worked around via the 'unset'
>> command:
>
> Until you define a function named unset.

Well, yes - that was the point of the paragraphs after the demonstration.

> But the real point here is that you should only use sudo or su (or
> doas or any other program that reads your password) from a trusted
> environment. What you definitely should NOT do is get called by a
> coworker, go over to their workstation, hear the description of a
> problem, and try to fix it from their computer, where they may have
> overridden su/sudo/etc.
>
> Go back to your own desk first, and fix it from there.

I wasn't even thinking of it in those terms, although now that you point
it out that's a good thing to be aware of. I was thinking of it in terms
of A: trying to write scripts that are safe against such problematic
elements being in the environment, and B: being able to detect and
recover from some piece of malware having inserted such elements into
the environment on your *own* computer.

Which is also about only doing it from a trusted environment, I suppose
- just with even more stringent and depressing considerations about what
the limitations of trustability are.

[Greg Wooledge]

On Fri, May 20, 2022 at 09:36:40PM -0400, The Wanderer wrote:
> I wasn't even thinking of it in those terms, although now that you point
> it out that's a good thing to be aware of. I was thinking of it in terms
> of A: trying to write scripts that are safe against such problematic
> elements being in the environment,

You can't. It's really that simple -- if someone can compromise the
execution environment of your script, they can make your script do
anything they like.

Don't think that compiled programs are safe, either -- unless they're
statically linked, someone with control over the execution environment
can use LD_PRELOAD or similar environment variables to override any
library function the program calls.

With that in mind, what you do as a programmer is simply ignore the
possibility. Your program should assume it's being run in a sane, or
at least non-malicious, environment.

At the programming level, your security responsibilities are things like:

* Use correct and safe programming practices for whatever language(s)
you're writing in.

* Sanity-check all user inputs, whether from files, from the environment,
or from a terminal, before you use them.

* Avoid writing programs that write programs whenever possible. If you
can't avoid them (e.g. if you *must* call awk from your bash script),
be on the lookout for code injections.

> and B: being able to detect and
> recover from some piece of malware having inserted such elements into
> the environment on your *own* computer.

Many people will tell you that if your computer has been compromised,
there's no recovering from it. It's best to wipe the file systems and
reinstall, then restore data from the last non-compromised backup.

A post-mortem analysis is possible, if you remove the hard drive(s) and
use them as non-booting data disks in another system. From a trusted
environment like that, you can mount the file systems and inspect them
to see what has been compromised. But it'll be tedious and time-consuming.

[Lee]

On 5/19/22, Tom Browder <tom.b...@gmail.com> wrote:
> On Thu, May 19, 2022 at 03:54 Kamil Jońca <kjo...@o2.pl> wrote:
>
>> It is quite misterious for me.
>> What is the purpose of "sudo su" instead of plain "sudo" or "sudo -i"

< .. snip ..>

>
> I have for years now not used the many variants of su, just "sudo" alone
> for one-off use and "sudo su" when I'm doing several things as root.

Why not "sudo bash" when you want to do several things as root?

Lee

[Tixy]

Don't think the mini.iso exists any more. I recently needed to install
Ubuntu and the only options I could find where the full Gnome GUI or
the Server install. I went for the latter with the extra crud that
pulls in because I wanted to start from as minimal install as I could
before adding the things I needed.

--
Tixy

[Brian]

Looks like the situation on jammy (22.04) is as you say. However, not
so for focal (20.04):

http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/

I downloaded the mini.iso last year and upgraded to jammy.

--
Brian.

[to...@tuxteam.de]

Well, that's what sudo -s and sudo -i do; only that they are smarter
than this and choose "your" (for one of several possible values of
"your") favourite shell (be it bash or other). Straight from the man
page:

-i, --login
Run the shell specified by the target user's password database
entry as a login shell. This means that login-specific resource
files such as .profile, .bash_profile or .login will be read
by the shell [...]

-s, --shell
Run the shell specified by the SHELL environment variable if
it is set or the shell specified by the invoking user's password
database entry [...]

Kids, read the man page ;-)

Less typing, more general. Nobody's trying to dissuade you of doing
"sudo bash" or "sudo su" or... (hey, let's play Rube Goldberg a bit)
"sudo perl -e 'system(bash)'". But most, most of the time, sudo -i
or sudo -s will do what you want.

Cheers
--
t

[Greg Wooledge]

On Sat, May 21, 2022 at 03:19:09PM +0200, to...@tuxteam.de wrote:
> Less typing, more general. Nobody's trying to dissuade you of doing
> "sudo bash" or "sudo su" or...

I'm definitely trying to dissuade people from doing the latter. It's
one of those horrible memes that has spread maliciously for a decade
or two, to the extent that many people actually think it's correct,
because they've seen it so often.

"sudo bash" isn't bad. It's the simplest and clearest way to choose
the shell you want to use after the privilege change, just in case
the user account you're switching to has something like /bin/true
listed as its shell, etc.

[Tom Browder]

On Sat, May 21, 2022 at 09:02 Greg Wooledge <gr...@wooledge.org> wrote:

On Sat, May 21, 2022 at 03:19:09PM +0200, to...@tuxteam.de wrote:
> Less typing, more general. Nobody's trying to dissuade you of doing
> "sudo bash" or "sudo su" or...

I am getting nowhere fast. I think all will be okay if (and only if) I can do these two things:

1. define root's path for a login shell

If I read the bash docs correctly, I can set the path in either /etc/profile or /root/.profile.

2. define root's path for a non-login shell

If I read the bash docs correctly, I can set the path either in /etc/bash.bashrc or /root/.bashrc.

If those assumptions are correct, then, with the proper incantation of a one-shot sudo command, the command should use the expected path for root and use a raku script to install a compiled C executable and its associated products (specifically openssl and apache2) to their proper places on the system, i.e., provide the same result as 'sudo make install'.

At this point I am not concerned with becoming root for multiple commands, just:

       $ sudo [perhaps with some sudo args] some-user-space-command with args

So, are my assumptions correct? If do, what are the proper sudo args for each use, if any?

Thanks.

-Tom

[Greg Wooledge]

On Sat, May 21, 2022 at 10:04:01AM -0500, Tom Browder wrote:
> I am getting nowhere fast.

OK, let's start at the beginning.

You have raku installed in some directory that is not in a regular PATH.

You won't tell us what this directory is, so let's pretend it's
/opt/raku/bin/raku.

You have added /opt/raku/bin to your regular account's PATH. The "raku"
command works as long as you are yourself.

You would like it to work after you use an elevation command to become
root.

So, I've already given you the solution that *I* would use, which is:

ln -s /opt/raku/bin/raku /usr/local/bin/raku

After that, you can remove /opt/raku/bin from your regular account's
PATH, if you wish. Or keep it. Either way is fine.

For some reason, however, you don't like this solution. You won't tell
us why. Maybe the voices in your head are telling you that symlinks
will corrupt your precious bodily fluids. Who knows.

So, you would like to perform a privilege elevation command and keep
your regular account's PATH variable.

Well, guess what? As it turns out, the incredibly stupid behavior of
buster's "su" command does exactly that.

There's your second solution: use "su" (without creating an /etc/default/su
config file) in buster or bullseye or later as your privilege elevation
command.

Next, of course, you will tell us that the voices in your head won't
permit this answer either, because no answer that you are given will
ever be acceptable.

The voices in your head will tell you that you absolutely must use
sudo to perform your privilege elevation.

Therefore the third solution for you: configure sudo so that it does
what you want.

Next, of course, the voices in your head will tell you that configuring
sudo is not permissible. You have to do this in... gods, I don't know...
a spun-up instance of a Docker system with no customization allowed.
You will require a solution that works in an absolutely vanilla unmodified
Debian-like mini-instance provided by some Docker idiot. And therefore
every solution offered will be unacceptable.

At that point, sod off.

[Linux-Fan]

Greg Wooledge writes:

> On Sat, May 21, 2022 at 10:04:01AM -0500, Tom Browder wrote:
> > I am getting nowhere fast.
>
> OK, let's start at the beginning.
>
> You have raku installed in some directory that is not in a regular PATH.
>
> You won't tell us what this directory is, so let's pretend it's
> /opt/raku/bin/raku.

[...]

> The voices in your head will tell you that you absolutely must use
> sudo to perform your privilege elevation.
>
> Therefore the third solution for you: configure sudo so that it does
> what you want.
>
> Next, of course, the voices in your head will tell you that configuring
> sudo is not permissible. You have to do this in... gods, I don't know...

[...]

There is also `sudo -E` to preserve environment and
`sudo --preserve-env=PATH` that could be used to probably achieve the
behaviour of interest. If this is not permitted by security policy but
arbitrary commands to run with sudo are, consider creating a startup script
(or passing it directly at the `sudo` commandline) that sets the necessary
environment for the raku program.

That being said: On my systems I mostly synchronize the bashrc of root and my
regular users such that all share the same PATH. I tend to interactively
become root and hence ensure that the scripts are run all of the time. This
has mostly survived the mentioned change in `su` behaviour and observable
variations between `sudo -s` and `su` behaviours are kept at a minimum.

HTH and YMMV
Linux-Fan

öö

[to...@tuxteam.de]

On Sat, May 21, 2022 at 06:04:07PM +0200, Linux-Fan wrote:
> Greg Wooledge writes:
>
> > On Sat, May 21, 2022 at 10:04:01AM -0500, Tom Browder wrote:
> > > I am getting nowhere fast.
> >
> > OK, let's start at the beginning.
> >
> > You have raku installed in some directory that is not in a regular PATH.
> >
> > You won't tell us what this directory is, so let's pretend it's
> > /opt/raku/bin/raku.
>
> [...]
>
> > The voices in your head will tell you that you absolutely must use
> > sudo to perform your privilege elevation.
> >
> > Therefore the third solution for you: configure sudo so that it does
> > what you want.
> >
> > Next, of course, the voices in your head will tell you that configuring
> > sudo is not permissible. You have to do this in... gods, I don't know...
>
> [...]
>
> There is also `sudo -E` to preserve environment and
> `sudo --preserve-env=PATH` that could be used to probably achieve the
> behaviour of interest.

Exactly. The man page tells us (hint, hint ;-)

-E doesn't preserve PATH on my system, but --preserve-env=PATH does.

This surely has to do with the "security policy" mentioned in the
man page (passing PATH to a root shell is a wonderful opportunity
for a root privilege escalation, after all, so it makes sense to
not establish it as a default).

I'm sure the OP is now able to locate that "security policy" config
and change it to taste. "--preserve-env=PATH" is quite a mouthful
and one doesn't want to type it all the time :-)

Cheers
--
t

[to...@tuxteam.de]

[reinserted the copy to list: others tend to have better
ideas than me]

On Sun, May 22, 2022 at 06:15:57AM -0500, Tom Browder wrote:
> On Sat, May 21, 2022 at 11:28 <to...@tuxteam.de> wrote:
> ...

>
> > I'm sure the OP is now able to locate that "security policy" config
> > and change it to taste. "--preserve-env=PATH" is quite a mouthful
> > and one doesn't want to type it all the time :-)
>
>

> I'm zeroing in on the solution your Socratic method is nudging me toward,
> but, at the CLI, I get results that are confusing, to wit:

Socratic -- I fear you over-estimate me badly :-)

> $ sudo -i raku -v
> Welcome to Rakudo...
>
> but
>
> $ sudo -E raku -v
> sudo: raku: command not found
>
> and also
>
> $ sudo --preserve-env raku -v
> sudo: raku: command not found

Note that the key --preserve-env takes an arg. That would be

--preserve-env=PATH

to pass on the PATH environment variable. The arg is a comma separated
list of environment variable names.

Cheers
>
> -Tom

[Tom Browder]

On Sun, May 22, 2022 at 09:02 <to...@tuxteam.de> wrote:

…

Socratic -- I fear you over-estimate me badly :-)

You are too modest!

Note that the key --preserve-env takes an arg. That would be

  --preserve-env=PATH

to pass on the PATH environment variable. The arg is a comma separated
list of environment variable names.

Yes, I actually used that syntax but failed to put it in the message—same result: 

     sudo —preserve-env=PATH raku -v

     sudo: raku: command not found

The only thing that worked was:

      $ sudo -i raku -v

and I can live with that for now.

But, if I try making an entry in a sudoer file (to eliminate needing the ‘-i’ arg), is this the right syntax:

    env_keep=PATH

Cheers!

-Tom

[Greg Wooledge]

On Sun, May 22, 2022 at 10:48:44AM -0500, Tom Browder wrote:
> Yes, I actually used that syntax but failed to put it in the message—same
> result:
>
> sudo —preserve-env=PATH raku -v
> sudo: raku: command not found

You might have misspelled --preserve. It's hard to tell, because
what you've got in your email message is a Unicode character, represented
in UTF-8 by the three bytes 0xe2 0x80 0x94. According to a Google search,
that's "em dash U+2014". So, it's not clear whether you actually
typed (or pasted) that em dash character into your shell, or whether
you had -- in your shell, but it somehow got mangled into em dash when
you pasted (or typed?) it into your email.

Somewhat to my surprise, sudo *does not* report an error if you feed it
an em dash in this position:

unicorn:~$ echo "$PATH"
/home/greg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/greg/.dotnet/tools:/sbin:/usr/sbin
unicorn:~$ sudo sh -c 'echo "$PATH"'
[sudo] password for greg:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
unicorn:~$ sudo --preserve-env=PATH sh -c 'echo "$PATH"'
/home/greg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/greg/.dotnet/tools:/sbin:/usr/sbin
unicorn:~$ sudo —preserve-env=PATH sh -c 'echo "$PATH"'
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

So... we literally can't tell what you did.

Still wondering why you can't just use the other solutions you've been
given. If it's the Docker thing, tell me now, so I can stop wasting my
time.

[Tom Browder]

On Sat, May 21, 2022 at 10:40 Greg Wooledge <gr...@wooledge.org> wrote:

...

So, I've already given you the solution that *I* would use, which is:

ln -s /opt/raku/bin/raku /usr/local/bin/raku

That works fine, but another part of the work flow for nstallation is the need to access another Raku program which must be run by both root and the user--linking doesn't work because of some subtleties I don't understand.

So far the use of "sudo -i some-command" works for my current needs. 

As I said a bit earlier: I can live with that.

-Tom

[Tom Browder]

On Sun, May 22, 2022 at 11:04 Greg Wooledge <gr...@wooledge.org> wrote:

...

So... we literally can't tell what you did.

I think that character munging is because of the unwanted, unedititible html mail from my ipad gmail client.

Still wondering why you can't just use the other solutions you've been
given.  If it's the Docker thing, tell me now, so I can stop wasting my
time.

The "sudo -i some-command" seems to satisfy my current needs. (And I am not a regular docker user yet.)

Thanks for your help, and please don't waste any more time on my account

-Tom

[Charles Kroeger]

> There is no silver bullet that makes your system secure.

I get a login shell with $su --login

I don't have sudo installed

is there something heretical about that, I should know?

[The Wanderer]

Not heretical, but - if something has compromised your user environment,
it could have replaced the command 'su' with a function which captures
the password you type, stores it for later use by malware (or even
uploads it to a remote server), and then invokes su properly (with the
same parameters you gave) so that you won't notice that this has happened.

The point / gist of this particular subthread seems to be that there is
no effective way to prevent this from happening - or even to *detect* it
with certainty, other than examining the hard drive while booted into a
running environment which has not itself been compromised.

(The old story about hacking the source of gcc to detect when it's
compiling /bin/login and insert a backdoor, and to detect when it's
compiling gcc and insert code to make it do both of these
detect-and-insert operations, comes to mind. That story as I learned it
always ended with the note that the guy doesn't *think* he ever let a
version of gcc which had been compiled to do these things out into the
wild... but he isn't completely certain.)

[basti]

Am 20.05.22 um 02:24 schrieb Kenneth Parker:

>
>
> On Thu, May 19, 2022, 4:14 AM 황병희 <soye...@doraji.xyz

> <mailto:soye...@doraji.xyz>> wrote:
>
> Tom Browder <tom.b...@gmail.com <mailto:tom.b...@gmail.com>>

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918754#41

or use su -l

[Greg Wooledge]

On Sun, May 22, 2022 at 09:37:43PM +0200, basti wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918754#41
>
> or use su -l

For the record, that URL says:

This is a new behavior because the util-linux implementation of su is
used now. See also /usr/share/doc/util-linux/NEWS.Debian.gz for more
information.

"If you want to restore behaviour more similar to
the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs."

The advice in the second paragraph will *technically* work, and for a
little while we thought it was the best available workaround.

However, there is a problem with that one: the settings in /etc/login.defs
are *also* read by the login(1) program. If you add the indicated line
to /etc/login.defs then you will get a warning every time you login on
a text console. The warning can be ignored, but it's confusing and scary.

Putting the line in /etc/default/su instead works much better. That file
isn't read by login(1), so you don't get scary warnings on console logins.
That's why we changed the wiki to support that solution instead of the
older one.

[to...@tuxteam.de]

On Sun, May 22, 2022 at 03:32:22PM -0400, The Wanderer wrote:
> On 2022-05-22 at 14:53, Charles Kroeger wrote:
>
> >> There is no silver bullet that makes your system secure.
> >
> > I get a login shell with $su --login
> >
> > I don't have sudo installed
> >
> > is there something heretical about that, I should know?
>
> Not heretical, but - if something has compromised your user environment,
> it could have replaced the command 'su' with a function which captures

> the password you type [...]

Less antagonistic, but also of practical importance -- sudo lets you
acquire usage patterns which improve your chances to not fat-finger
things.

As others have said, sudo can be subverted (nearly) as easily as
su can. IOW, if someone has control of your execution environment
and if you can reach privilege escalation from there, all bets are
up.

[...]

> (The old story about hacking the source of gcc to detect when it's
> compiling /bin/login and insert a backdoor, and to detect when it's
> compiling gcc and insert code to make it do both of these

> detect-and-insert operations [...]

That would be Ken Thompson's 1983 Turing Award lecture [1]. Much
recommended.

But not all is lost. David A. Wheeler (a free software and Linux
regular, BTW) has taken on this [2]. Here's Bruce Schneier on
Wheeler's paper [3].

Cheers

]1] https://dl.acm.org/doi/10.1145/358198.358210
[2] https://dwheeler.com/trusting-trust/
[3] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

--
tomás

[Lee]

If this is for your personal machine, no.

If this is a multi-user environment, you should be changing the root
password whenever someone that knows the root password leaves. If you
use sudo exclusively to get root permissions then the number of people
leaving that could require a root password change is potentially
smaller.

Lee