On Wed 26 Mar 2025 at 16:24:21 (+0300), J wrote: > ср, 26 мар. 2025 г. в 16:10, Greg Wooledge <g...@wooledge.org>: > > On Wed, Mar 26, 2025 at 07:48:16 -0500, Richard Owlett wrote: > > > On 3/26/25 6:55 AM, Greg Wooledge wrote: > > > > I normally use "sudo -s", which is the closest sudo approximation to > > > > the traditional behvior of "su" (before it was broken in buster). > > > > Out of the box, in Debian 1.1 through 9, "su" with no arguments would > > give you a root shell with the PATH variable changed to include > > /usr/local/sbin, /usr/sbin and /sbin. > > > > Out of the box, in Debian 10 and later, "su" with no arguments no > > longer changes the PATH variable. Your root shell has the same PATH > > as your previous shell, with directories like /usr/games but not > > /usr/sbin or /sbin. > > > > This caused ALL KINDS of problems. People would do things like: > > > > $ su > > # apt update > > # apt install somepkg > > > > And the postinstall script for somepkg would fail because it couldn't > > find commands that are in /sbin or /usr/sbin, because those directories > > which should have been in PATH, which *had* been in PATH for the last > > 20 years, were suddenly not there. > > > > Some people proposed using "su -" as a workaround. And this is fine for > > many situations: > > > > $ su - > > # apt update > > # apt install somepkg > > > > Here, it works fine. The commands spawned by apt to install the package > > don't care what directory they're executed from. > > > > But in other cases, it's not fine: > > > > $ cd /somewhere/that/is/obnoxiously/long/program-1.2.3 > > $ ./configure > > $ make > > $ su - > > # make install > > > > Whoopsie! That just blew up catastrophically, because su - changes > > your working directory. You're no longer in the > > /somewhere/that/is/obnoxiously/long/program-1.2.3 directory, so you're > > no longer in the right place for "make install" to work from. > > > > > Does this "brokenness" of "su" have any potential effect on my usage? > > > > Maybe. If you haven't created an /etc/default/su file, then something > > like this: > > > > $ su > > # adduser richard > > > > may fail. You could work around it in various ways (e.g. explicitly > > typing out /usr/sbin/adduser richard). > > > > My recommendation is to create a one-line configuration file: > > > > hobbit:~$ cat /etc/default/su > > ALWAYS_SET_PATH yes > > > > That's all it takes. With this file, with this setting, "su" with no > > arguments will behave the way it's supposed to: it changes PATH without > > changing your working directory. > > > So, in most cases* sudo -s* is better? Any downsides?
People vary, and so their working methods do too. You need to make your own choices that you're happy with, while avoiding doing anything too dangerous. I like systems to come up in a known, consistent state, so I've been using su - since the last century. My prompt always shows who I am (with reverse video as root), the host (colour), and working directory. So for the problem of retaining the cwd, I just: host!auser 09:57:47 /somewhere/that/is/obnoxiously/long/program-1.2.3$ /bin/su --login Password: bullseye on /dev/sda5 toto05 host 09:57:59 ~# cd /somewhere/that/is/obnoxiously/long/program-1.2.3 host 09:58:08 /somewhere/that/is/obnoxiously/long/program-1.2.3# where that's a simple cut and paste. I have a file in /etc/sudoers.d/ with tailored commands for all the routine stuff that I need root for, so I switch to root for things that are out of the ordinary. Similarly, I've always locked down my mc configuration, so changes I make don't stick. More idiosyncratically, I also load a fixed bash_history file with each xterm, so history added during the day is thrown away when I close down. (Which goes to explain my use of the rather prolix /bin/su --login above.) So I think you can see that /I/ wouldn't want to run an environment that's a mixture of an ordinary user's and root's. Cheers, David.
