Comment # 20 on bug 1170443 from Josef M�llers

(In reply to Rainer Klier from comment #19)
> (In reply to Josef M�llers from comment #18)
> > (In reply to Rainer Klier from comment #17)
> > > (In reply to Josef M�llers from comment #16)
> > > > (In reply to Rainer Klier from comment #13)
> > > > > (In reply to Stanislav Brabec from comment #12)
> > > > > > Does your su binary have SUID flag?
> > > > > 
> > > > Can you please try to change that to
> > > > -rwsr-xr-x 1 root root 51320 15. Apr 20:10 /usr/bin/su
> > > > eg by "chmod 4755 /usr/bin/su" and try to reproduce the error?
> > > 
> > > it works now! :-D
> 
> and is the "s" bit the correct way, how it should be?

Sorry if I state the obvious: usually a program runs with the privileges of the
user who executes it. So eg you won't be able to show the /etc/shadow file by
using "cat /etc/shadow" because an unprivileged user has no rights to open and
read that file. But as sometimes a non-privileged user needs to do something
that requires higher privileges, the SETUID bit changes the privileges to the
OWNER OF THE FILE, "root" in the case of "su". Then, "su" can open
"/etc/shadow" (using the PAM library) and do what it needs to do. These
programs are highly sensitive and are scrutinized carefully by multiple people.

The "x" in the 4th position usually indicates execute permission for the owner
of the file (int the 7th position of users in the same group and in the 11th
position for everyone else). If the SETUID (SET User ID) bit is set, it is
shown in this position as "S" if the execute bit is NOT set and as "s" if the
execute bit is also set, so in this case, as the "su" program must be
executable, it should show as "s". (The SETGID (SET Group ID) bit is likewise
shown in the 7th position, another bit, the "RESTRICTED DELETION FLAG OR STICKY
BIT" is shown as T/t in the 11th position.

> > > so, could it be, that an update on 2020-04-24 changed the SUID flag on the
> > > su command?
> > 
> > This is highly unlikely:
> > 1) It would need to be changed explicitly in the package's build
> > infrastructure
> > 2) As packages are tested before being released, this would definitely have
> > shown up in these tests.
> 
> so, the one question remains open:
> WHY it was suddenly changed?
> 
> i didn't do it.

Unless Stanislav has an explanation, I venture to say: this kind of things
happens ... I'm in this business for ~40 years and I claim that it has happened
to me one time or another. I don't want to finger-point in any way. As Linux
tools are very quiet if they think they did The Right Thing, one often doesn't
see what has really happened. Also, some of these bits are reset if you fiddle
around with these files in one way or another, so it may have happened when you
did something else.

> > So, in a nutshell: I'm (really!) afraid we won't know what the root cause
> > for this problem is.
> 
> yes, that is the remaining problem....

As I wrote: "I'm (really!) afraid" as, believe me, this kind of solution is
highly unsatisfactory: not being able to get to the root cause leaves an eary
feeling that something MAY be wrong.

> > So I'm closing this bug as FIXED. If you feel this is incorrect, please
> > re-open.
> 
> ok, if the "s" bit is the correct solution, it is ok for me.
> if this problem returns, i know, where to look and check.
> and if it returns, i will reopen this ticket.

Yes. That's how it should be done.

> thank you very much.

That's also what we're here for!