Re: Odd reproducible problem - but is it a bug?

[Nicolas George]

Anders Andersson (12022-05-04):
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.

I have to unpack Zip files rather often, I use unzip in command-line. It
has become an automatism: “unz/tmp/...”.

Recently, initrd-tools complained that zstd was not installed, so I
installed it.

The next time I had a Zip file to unpack, I typed “unz” and was
confused that it did not work: “unz” had become ambiguous between
“unzip(sfx)” and “unzstd”.

Every program in the search path clutters the namespace and makes the
shell completion less efficient. When a program is useful for a normal
user once every 36th of the month, I would rather not have it in the
default search path: typing “/sb” then is cheap enough for the
benefit of gaining a few keystrokes for commands I use many times a day.

YMMV.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Odd reproducible problem - but is it a bug?

[Greg Wooledge]

On Wed, May 04, 2022 at 07:04:52AM -0600, Charles Curley wrote:
> On Wed, 4 May 2022 05:23:31 +0200
> Anders Andersson  wrote:
> 
> > On this note, I've always found it annoying that debian (and likely
> > others) don't put /sbin in the normal user's $PATH. A lot of the tools
> > there have uses other than modifying the system.
> 
> It can be annoying, but for good reason. In a multi-user system (such
> as Unix), it is a good security precaution to reserve programs that can
> modify or even inform the user about the state of the system to trusted
> users, such as root or wheel. Hence regular programs for regular users
> go into directories called bin, and system programs go into directories
> called sbin, and paths are set accordingly.

That is the most ludicrous thing I've heard in... a long time.

If a command can reveal sensitive information to an unprivileged user,
then "hiding" it in /sbin is not a valid security measure.  The smart
user will simply run /sbin/whatever, or change their PATH variable to
include /sbin.

Of course, your assertion that any command *could* reveal such sensitive
information is laughable.  Programs can only do the things allowed by
their privileges.  If joe tries to read the /etc/shadow file, he can't
do it, because he doesn't have the correct privileges.  None of the
commands in /sbin are going to be able to do it either, because they
run *as joe*.

(Obviously, setuid or setgid programs could exist which run with elevated
privileges.  Those have to be written correctly.  If one of them has a
security hole, just hiding it in /sbin *does not count* as a security
improvement on your system.)

> Even on a single user system the distinction is worth retaining. If
> nothing else, one occasionally needs a reminder to be careful with
> certain programs lest one shoot oneself in the foot.

There are several reasons why /sbin exists, historically.

On some systems, the programs in /sbin are *statically linked*.  That's
what the 's' actually stands for -- not 's'ecure, not 's'uperuser, but
's'tatic.  They're needed during boot, at a time when the file system
which contains the shared libraries used by commands in /bin may not be
mounted yet.

HP-UX is one such system.  /bin is a symlink to /usr/bin, and there are
both /usr/bin/cat and /sbin/cat commands.  Shell scripts which must run
during the early stages of boot can use /sbin/cat (along with redirections)
to copy files, or display simple messages.

On most other systems, the programs in /sbin are not statically linked,
but are placed there for other reasons.

One reason is simply that these programs don't *do* anything useful or
helpful for ordinary users.  They may not even run at all.

Another reason is to reduce the size of the /usr/bin and /bin directories,
for performance.  It's a tiny gain, but over years of operation, it could
add up to something noticeable.

The main reason is "because that's where it has always been".  This is
both for user expectations, and for backward compatibility in case some
idiot hard-coded /sbin/ifconfig in a shell script.  Keeping the commands
in their historic locations will prevent a few badly-written scripts
from breaking.

Re: Odd reproducible problem - but is it a bug?

[Charles Curley]

On Wed, 4 May 2022 05:23:31 +0200
Anders Andersson  wrote:

> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.

It can be annoying, but for good reason. In a multi-user system (such
as Unix), it is a good security precaution to reserve programs that can
modify or even inform the user about the state of the system to trusted
users, such as root or wheel. Hence regular programs for regular users
go into directories called bin, and system programs go into directories
called sbin, and paths are set accordingly.

Even on a single user system the distinction is worth retaining. If
nothing else, one occasionally needs a reminder to be careful with
certain programs lest one shoot oneself in the foot.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Odd reproducible problem - but is it a bug?

[tomas]

On Wed, May 04, 2022 at 05:23:31AM +0200, Anders Andersson wrote:

[on sbin]

> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.

I've grown accustomed to that. For example, `ifconfig' is just named
`/sbin/ifconfig'.

That said, the pattern seems to be dying out. Ifconfig's new and
all-shiny cousin, ip,  already is lodged in /bin, so there you go.
My muscle memory has adapted.

I don't think you can convince others to follow along, so you're
better off "enhancing", e.g. your /etc/profile. That's what it's
for, after all :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Odd reproducible problem - but is it a bug?

[Anders Andersson]

On Mon, May 2, 2022 at 8:19 PM  wrote:
> On Mon, May 02, 2022 at 07:58:12PM +0200, Michael Lange wrote:
> > On Mon, 2 May 2022 10:17:06 -0500
> > Richard Owlett  wrote:
> > > I'm using Debian 10.7 with MATE DE [will be updated later this week]
> > > The machine is a Lenovo T510 and is setup to login as either "richard"
> > > or "root".
> > >
> > > If logged in as "richard" I can execute su {+ password} and receive a
> > > prompt indicating I'm "root".
> > >
> > > However if I then enter "update-grub", the response is
> > >"bash: update-grub: command not found"
> > > as if I were the unprivileged user "richard".
> >
> > you need to do
> >
> >  # su -
> >
> > (instead of just
> >
> >  # su
> > ),
> > otherwise $PATH will be inherited from user "richard" and thus lack the
> > entry "/sbin".
>
> Or just get used to say "/sbin/update-grub" ;-)
>
> (No, I'm not really being serious here. But half-acquiring this
> habit would have helped you to unravel the problem like in "Ah,
> I have the permissions but not the $PATH..."

On this note, I've always found it annoying that debian (and likely
others) don't put /sbin in the normal user's $PATH. A lot of the tools
there have uses other than modifying the system.

Re: Odd reproducible problem - but is it a bug?

[tomas]

On Mon, May 02, 2022 at 07:58:12PM +0200, Michael Lange wrote:
> Hi,
> 
> On Mon, 2 May 2022 10:17:06 -0500
> Richard Owlett  wrote:
> 
> > I'm using Debian 10.7 with MATE DE [will be updated later this week]
> > The machine is a Lenovo T510 and is setup to login as either "richard" 
> > or "root".
> > 
> > If logged in as "richard" I can execute su {+ password} and receive a 
> > prompt indicating I'm "root".
> > 
> > However if I then enter "update-grub", the response is
> >"bash: update-grub: command not found"
> > as if I were the unprivileged user "richard".
> 
> you need to do 
> 
>  # su -
> 
> (instead of just
> 
>  # su
> ),
> otherwise $PATH will be inherited from user "richard" and thus lack the
> entry "/sbin".

Or just get used to say "/sbin/update-grub" ;-)

(No, I'm not really being serious here. But half-acquiring this
habit would have helped you to unravel the problem like in "Ah,
I have the permissions but not the $PATH..."

It's no different from the TVs of yore: is it the driver stage
to the high voltage, or did just the capacitor short? What can
I do to tell apart those two?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Odd reproducible problem - but is it a bug?

[Michael Lange]

Hi,

On Mon, 2 May 2022 10:17:06 -0500
Richard Owlett  wrote:

> I'm using Debian 10.7 with MATE DE [will be updated later this week]
> The machine is a Lenovo T510 and is setup to login as either "richard" 
> or "root".
> 
> If logged in as "richard" I can execute su {+ password} and receive a 
> prompt indicating I'm "root".
> 
> However if I then enter "update-grub", the response is
>"bash: update-grub: command not found"
> as if I were the unprivileged user "richard".

you need to do 

 # su -

(instead of just

 # su
),
otherwise $PATH will be inherited from user "richard" and thus lack the
entry "/sbin".

Have a nice day,

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Ahead warp factor one, Mr. Sulu.

Re: Odd reproducible problem - but is it a bug?

[Greg Wooledge]

On Mon, May 02, 2022 at 03:43:41PM +, Andrew M.A. Cater wrote:
> Not bug - feature.

I disagree.  Strongly.  It is a CHANGE, but it is not a feature.

> See also su -
> 
> It's in the release notes, I'm fairly sure.

It's also at .  It has also
been discussed to death and beyond on this mailing list.  Literally
dozens, if not hundreds, of message have been posted about it over the
last couple years.

The fact that the OP never read any of them somehow fails to surprise me.

(Almost as much as the Debian maintainers refusing to ship a one-line
/etc/default/su file to fix the behavior of su fails to surprise me at
this point.  Fortunately, we can create that file ourselves and get
things back to normal.)

Re: Odd reproducible problem - but is it a bug?

[Andrew M.A. Cater]

On Mon, May 02, 2022 at 10:17:06AM -0500, Richard Owlett wrote:
> I'm using Debian 10.7 with MATE DE [will be updated later this week]
> The machine is a Lenovo T510 and is setup to login as either "richard" or
> "root".
> 
> If logged in as "richard" I can execute su {+ password} and receive a prompt
> indicating I'm "root".
> 
> However if I then enter "update-grub", the response is
>   "bash: update-grub: command not found"
> as if I were the unprivileged user "richard".
> 
> All is normal if I had initially been "root" or had become "root" via
> System -> Log Out richard  .
> 
> Bug?
> 
>

Hi Richard,

Not bug - feature. See also su -

It's in the release notes, I'm fairly sure.

All the very best, as ever,

Andy Cater 

Re: Odd reproducible problem - but is it a bug?

[Lucio Crusca]

Il 02/05/22 17:17, Richard Owlett ha scritto:
If logged in as "richard" I can execute su {+ password} and receive a 
prompt indicating I'm "root".


   "bash: update-grub: command not found"

Bug?



No, it's only an effect of the PATH variable. Try "su -".

Odd reproducible problem - but is it a bug?

[Richard Owlett]

I'm using Debian 10.7 with MATE DE [will be updated later this week]
The machine is a Lenovo T510 and is setup to login as either "richard" 
or "root".


If logged in as "richard" I can execute su {+ password} and receive a 
prompt indicating I'm "root".


However if I then enter "update-grub", the response is
  "bash: update-grub: command not found"
as if I were the unprivileged user "richard".

All is normal if I had initially been "root" or had become "root" via
System -> Log Out richard  .

Bug?