Greg Wooledge (HE12025-03-26):
> 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.
That, I would argue, is a flaw in apt: it should have set the path to a
known valid one, possibly even excluding /usr/local/bin in case
incompatible commands are in it.
> $ su -
> # make install
>
> Whoopsie!
Oh, even:
$ su
# make install
Whoopsie! The Makefile just pwned you. Or the non-hostile Makefile just
overwrote some files you had not yet saved. People who run make install
with extended privileges deserve what they get. Much safer to do:
$ make DESTDIR=/tmp/i install
$ sudo cp -r /tmp/i/blabla /blabla
Will not work if what is installed there requires unusual file
permissions, but in that case it is better to review everything anyway.
Using fakeroot + tar is an option.
> My recommendation is to create a one-line configuration file:
My recommendation is to learn to use sudo itself rather than trying to
emulate su. Having the privileged commands logged is a good idea. Using
privileges only with commands that need it is a good idea. Having the
same shell history for those is convenient.
Regards,
--
Nicolas George
