http://bugzilla.suse.com/show_bug.cgi?id=1170443
http://bugzilla.suse.com/show_bug.cgi?id=1170443#c20
--- Comment #20 from Josef Möllers
(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! -- You are receiving this mail because: You are on the CC list for the bug.