[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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.


Reply to: