Bug 1170443 - su seems to not work any more
su seems to not work any more
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: Josef Möllers
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-24 12:00 UTC by Rainer Klier
Modified: 2020-05-26 09:24 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
rainer.klier: needinfo?
rainer.klier: SHIP_STOPPER?


Attachments
result of 'supportconfig -z' (2.08 MB, application/x-bzip-compressed-tar)
2020-04-24 12:00 UTC, Rainer Klier
Details
tar -cvjf /tmp/pam.d.20200424.tar.bz2 etc/pam.d usr/etc/pam.d (9.00 KB, application/x-bzip)
2020-04-24 17:17 UTC, Rainer Klier
Details
/usr/etc/default/su (203 bytes, text/plain)
2020-05-04 06:50 UTC, Rainer Klier
Details
/usr/etc/login.defs (9.94 KB, text/plain)
2020-05-04 06:51 UTC, Rainer Klier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Klier 2020-04-24 12:00:54 UTC
Created attachment 836710 [details]
result of 'supportconfig -z'

since today i can't open YaST any more as normal user via kdesu because it tells me "access denied.  maybe password is wrong", even i know the root password and i typed it in correctly and also checked with the "eye" icon to see the password, before clicking on "ok".

this is what i found with 'journalctl --reverse':

Apr 24 13:53:19 lap051-linux su[6383]: FAILED SU (to root) rainer on pts/31
Apr 24 13:53:17 lap051-linux su[6383]: pam_unix(su:auth): authentication failure; logname= uid=1000 euid=1000 tty=pts/31 ruser=rainer rhost=  user=root
Apr 24 13:53:17 lap051-linux unix_chkpwd[6384]: password check failed for user (root)
Apr 24 13:53:17 lap051-linux unix_chkpwd[6384]: check pass; user unknown

i have attached the result of 'supportconfig -z'
Comment 1 Josef Möllers 2020-04-24 15:06:45 UTC
I cannot reproduce the issue on my TW VM.

For GDPR reasons (which were heavily debated), /etc/pam.d and /usr/etc/pam.d are not included in supportconfig any more (see /usr/lib/supportconfig/resources/supportconfig.rc, search for FORCE_OPTION_PAM, it can be switched on again by putting "FORCE_OPTION_PAM=1" into /etc/supportconfig.conf).

Could you please gather the pam.d files into an archive and attach that here?
Best would be to "cd /" and then "tar cvjf /tmp/pam.tbz etc/pam.d usr/etc/pam.d".
As these files are world-readable, they will not contain passwords or user names but feel free to check.

Can you also please check if (/usr)/etc/default/su are empty, if they exist?

Thanks and ... stay healthy.
Comment 2 Rainer Klier 2020-04-24 17:17:47 UTC
Created attachment 836740 [details]
tar -cvjf /tmp/pam.d.20200424.tar.bz2 etc/pam.d usr/etc/pam.d
Comment 3 Rainer Klier 2020-04-24 17:18:55 UTC
hi josef,

(In reply to Josef Möllers from comment #1)
> I cannot reproduce the issue on my TW VM.

I feared that....

> For GDPR reasons (which were heavily debated), /etc/pam.d and /usr/etc/pam.d
> are not included in supportconfig any more (see

i saw that, when running supportconfig.
but didn't know how to enable it.

> /usr/lib/supportconfig/resources/supportconfig.rc, search for
> FORCE_OPTION_PAM, it can be switched on again by putting
> "FORCE_OPTION_PAM=1" into /etc/supportconfig.conf).

ok, thanks.

> Could you please gather the pam.d files into an archive and attach that here?
> Best would be to "cd /" and then "tar cvjf /tmp/pam.tbz etc/pam.d
> usr/etc/pam.d".
> As these files are world-readable, they will not contain passwords or user
> names but feel free to check.

archive is attached.

> 
> Can you also please check if (/usr)/etc/default/su are empty, if they exist?

/etc/default/su does not exist

/usr/etc/default/su exists, but contains only comments:
# /etc/default/su is an override of /etc/login.defs for su.
# See /etc/login.defs and su(1) for more.
#
# List of supported variables:
# ALWAYS_SET_PATH, ENV_PATH, ENV_ROOTPATH, ENV_SUPATH, FAIL_DELAY
#
Comment 4 Frank Krüger 2020-04-24 18:45:27 UTC
I do not experience your issue with TW20200422. Anyway, what is the result of 'su -c whoami'?
Comment 5 Rainer Klier 2020-04-24 19:44:06 UTC
(In reply to Frank Kruger from comment #4)
> I do not experience your issue with TW20200422. Anyway, what is the result
> of 'su -c whoami'?

rainer@lap051-linux:/> su -c whoami
Passwort: 
su: Fehler bei Authentifizierung

journalctl --reverse gives:

Apr 24 21:42:45 lap051-linux su[12443]: FAILED SU (to root) rainer on pts/20
Apr 24 21:42:43 lap051-linux su[12443]: pam_unix(su:auth): authentication failure; logname=rainer uid=1000 euid=1000 tty=pts/20 ruser=rainer rhost=  user=root
Apr 24 21:42:43 lap051-linux unix_chkpwd[12445]: password check failed for user (root)
Apr 24 21:42:43 lap051-linux unix_chkpwd[12445]: check pass; user unknown
Comment 6 Rainer Klier 2020-04-24 19:49:19 UTC
to be sure that it is not the case, that somehow the root password has changed, i did "passwd" as root user and set it to the value it should currently be.

but it didn't change anything.

"su -" also fails.

for some unknown reasons any attempt to use "su" does not work, so it is a problem with su and not kdesu.
Comment 7 Frank Krüger 2020-04-24 20:32:08 UTC
(In reply to Rainer Klier from comment #6)
> to be sure that it is not the case, that somehow the root password has
> changed, i did "passwd" as root user and set it to the value it should
> currently be.
> 
> but it didn't change anything.
> 
> "su -" also fails.
> 
> for some unknown reasons any attempt to use "su" does not work, so it is a
> problem with su and not kdesu.

So, the issue is not due to kdesu. Could you please run 'sudo bash'?
Comment 8 Wolfgang Bauer 2020-04-24 22:59:23 UTC
(In reply to Frank Kruger from comment #7)
> (In reply to Rainer Klier from comment #6)
> > to be sure that it is not the case, that somehow the root password has
> > changed, i did "passwd" as root user and set it to the value it should
> > currently be.
> > 
> > but it didn't change anything.
> > 
> > "su -" also fails.
> > 
> > for some unknown reasons any attempt to use "su" does not work, so it is a
> > problem with su and not kdesu.
> 
> So, the issue is not due to kdesu. Could you please run 'sudo bash'?

And therefore "KDE Workspace (Plasma)" is certainly the wrong component here too.
Maybe "Basesystem is better"...
Comment 9 Rainer Klier 2020-04-24 23:35:40 UTC
(In reply to Frank Kruger from comment #7)
> (In reply to Rainer Klier from comment #6)
> > "su -" also fails.
> > 
> > for some unknown reasons any attempt to use "su" does not work, so it is a
> > problem with su and not kdesu.
> 
> So, the issue is not due to kdesu. Could you please run 'sudo bash'?

"sudo bash" works.

also "sudo su -"

but i think this is because my user is in group "wheel".

and the relevant part of "/etc/sudoers" looks like this:
##
## User privilege specification
##
root ALL=(ALL) ALL

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password
%wheel ALL=(ALL) NOPASSWD: ALL



thank god i put my user in group "wheel", because i think this is the only way currently to run a program as root....
Comment 10 Wolfgang Bauer 2020-04-24 23:54:42 UTC
FYI, it is possible to configure kdesu to use sudo instead of su to gain root privileges:
kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo
(run that as the user, not as root)

Of course that doesn't fix your actual problem that su doesn't work, but it should "fix" kdesu at least...
Comment 11 Josef Möllers 2020-04-27 07:42:05 UTC
Adding Stanislav Brabec for CC.
Stanislav, can you please have a look at this? I wonder why "root" is unknown ;-)
Comment 12 Stanislav Brabec 2020-05-04 00:27:06 UTC
Does your su binary have SUID flag?

"check pass; user unknown" does not come from su. It comes from PAM.

It is present in two places:
helper_verify_password(): if (pwd == NULL || salt == NULL)
_unix_verify_password()

"password check failed for user root" also comes from PAM: unix_chkpwd

You can try to debug option to the pam_unix.so line in /etc/pam.d/common-password.

There was a su configuration parsing behavior fix several months ago. Your configuration is the new default. Most users will not need to modify (/usr)/etc/default/su, (/usr)/etc/login.defs is sufficient.

Did you any changes in (/usr)/etc/login.defs?
Comment 13 Rainer Klier 2020-05-04 06:49:51 UTC
(In reply to Stanislav Brabec from comment #12)
> Does your su binary have SUID flag?

no:
"ll /usr/bin/su"
-rwxr-xr-x 1 root root 51320 15. Apr 20:10 /usr/bin/su

> "password check failed for user root" also comes from PAM: unix_chkpwd

i was assuming, all this comes somehow from PAM....

> You can try to debug option to the pam_unix.so line in
> /etc/pam.d/common-password.

how can i do this?

> There was a su configuration parsing behavior fix several months ago. Your

strange thing is, that i noticed problem at 2020-04-24.

> configuration is the new default. Most users will not need to modify
> (/usr)/etc/default/su, (/usr)/etc/login.defs is sufficient.

/etc/default/su and /etc/login.defs don't exist.


> Did you any changes in (/usr)/etc/login.defs?

no.

i will attach /usr/etc/default/su and /usr/etc/login.defs
Comment 14 Rainer Klier 2020-05-04 06:50:50 UTC
Created attachment 837306 [details]
/usr/etc/default/su
Comment 15 Rainer Klier 2020-05-04 06:51:12 UTC
Created attachment 837307 [details]
/usr/etc/login.defs
Comment 16 Josef Möllers 2020-05-04 06:59:25 UTC
(In reply to Rainer Klier from comment #13)
> (In reply to Stanislav Brabec from comment #12)
> > Does your su binary have SUID flag?
> 
> no:
> "ll /usr/bin/su"
> -rwxr-xr-x 1 root root 51320 15. Apr 20:10 /usr/bin/su

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?
Comment 17 Rainer Klier 2020-05-04 07:38:45 UTC
(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?
> > 
> > no:
> > "ll /usr/bin/su"
> > -rwxr-xr-x 1 root root 51320 15. Apr 20:10 /usr/bin/su
> 
> 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

"ll /usr/bin/su"
-rwsr-xr-x 1 root root 51320 Apr 15 20:10 /usr/bin/s

also kdesu works.

thanks.
so, could it be, that an update on 2020-04-24 changed the SUID flag on the su command?
Comment 18 Josef Möllers 2020-05-04 08:34:08 UTC
(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?
> > > 
> > > no:
> > > "ll /usr/bin/su"
> > > -rwxr-xr-x 1 root root 51320 15. Apr 20:10 /usr/bin/su
> > 
> > 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

Good news.

> "ll /usr/bin/su"
> -rwsr-xr-x 1 root root 51320 Apr 15 20:10 /usr/bin/s
> 
> also kdesu works.
> 
> thanks.
> 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, in a nutshell: I'm (really!) afraid we won't know what the root cause for this problem is.

So I'm closing this bug as FIXED. If you feel this is incorrect, please re-open.
Comment 19 Rainer Klier 2020-05-04 09:03:06 UTC
(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?

> > 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.

> 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....

> 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.

thank you very much.
Comment 20 Josef Möllers 2020-05-04 10:08:33 UTC
(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!
Comment 21 Stanislav Brabec 2020-05-05 04:51:12 UTC
There is a strange change:

Leap 15.1:
rpm -qlvp util-linux-2.33.1-lp152.4.55.x86_64.rpm 2>/dev/null | grep /usr/bin/su
-rwsr-xr-x    1 root     root                    59520 dub 14 16:44 /usr/bin/su
   ^

Tumbleweed:
rpm -qlvp util-linux-2.35.1-1.1.x86_64.rpm 2>/dev/null | grep /usr/bin/su
-rwxr-xr-x    1 root     root                    51320 dub 15 20:10 /usr/bin/su
   ^

There was not any relevant change in the spec file. Maybe in rpm or so.

It did not have SUID flag in /home/abuild/rpmbuild/BUILDROOT/util-linux-2.33.1-0.x86_64/usr/bin/su

But anyways, the change should not affect, as permissions are set by:

%post
...
%set_permissions %{_bindir}/su                                                                                                                                                                

You could check your installation log. Maybe this command failed or you set paranoid security profile.

/etc/permissions.paranoid:
/usr/bin/su                                             root:root         0755
Comment 22 Rainer Klier 2020-05-06 09:33:54 UTC
(In reply to Stanislav Brabec from comment #21)
> There is a strange change:
> 
> Leap 15.1:
> rpm -qlvp util-linux-2.33.1-lp152.4.55.x86_64.rpm 2>/dev/null | grep
> /usr/bin/su
> -rwsr-xr-x    1 root     root                    59520 dub 14 16:44
> /usr/bin/su
>    ^
> 
> Tumbleweed:
> rpm -qlvp util-linux-2.35.1-1.1.x86_64.rpm 2>/dev/null | grep /usr/bin/su
> -rwxr-xr-x    1 root     root                    51320 dub 15 20:10
> /usr/bin/su
>    ^

ok, so the "s" bit was not set before on my tumbleweed installation.
this is what i said.

> You could check your installation log. Maybe this command failed or you set

where should i look for what?
/var/log/YaST2/y2log?

> paranoid security profile.

where can i set this?

> /etc/permissions.paranoid:
> /usr/bin/su                                             root:root        
> 0755

i only have /etc/permissions.local which only has comments, and folder /etc/permissions.d, which only has 2 files:
-rw-r--r-- 1 root root 214 Apr 29 21:27 postfix
-rw-r--r-- 1 root root 126 Apr 29 21:27 postfix.paranoid
Comment 23 Stanislav Brabec 2020-05-25 02:05:41 UTC
>ok, so the "s" bit was not set before on my tumbleweed installation.
>this is what i said.

It was not set in the rpm database. It was set in %post by
%set_permissions %{_bindir}/su

>> You could check your installation log. Maybe this command failed or you set
>
>where should i look for what?
>/var/log/YaST2/y2log?
Yes. Please check for possible util-linux %post failure.

>> paranoid security profile.
>
>where can i set this?

PERMISSION_SECURITY in /etc/sysconfig/security

If you did not touch it, you don't have paranoid more. In this mode, many things don't work as most users want.

> /etc/permissions.paranoid:
> /usr/bin/su                                             root:root        
> 0755

>i only have /etc/permissions.local which only has comments, and folder >/etc/permissions.d, which only has 2 files:
>-rw-r--r-- 1 root root 214 Apr 29 21:27 postfix
>-rw-r--r-- 1 root root 126 Apr 29 21:27 postfix.paranoid

That looks strange.
If /etc/permissions.easy does not exist, it will not work.

/etc/permissions.easy is part of permissions package, and it contains line:
/bin/su                                                 root:root         4755

Please try "rpm -V permissions".
Comment 24 Rainer Klier 2020-05-26 09:24:19 UTC
hi,

(In reply to Stanislav Brabec from comment #23)
> 
> It was not set in the rpm database. It was set in %post by
> %set_permissions %{_bindir}/su
> 
> >> You could check your installation log. Maybe this command failed or you set
> >
> >where should i look for what?
> >/var/log/YaST2/y2log?
> Yes. Please check for possible util-linux %post failure.

ok, i didn't find anything in /var/log/YaST2/y2log about util-linux.
i searched with: grep -i util-linux /var/log/YaST2/y2log

> >where can i set this?
> 
> PERMISSION_SECURITY in /etc/sysconfig/security


this is what i have in /etc/sysconfig/security regarding PERMISSION_SECURITY:

## Path:        System/Security/Permissions
## Description: Configuration of permissions on the system
## Type:        string
## Default:     "easy local"
#
# Permission settings to use. By default 'easy', 'secure' and
# 'paranoid' exist. You may define your own though.
#
PERMISSION_SECURITY="easy local"



> If you did not touch it, you don't have paranoid more. In this mode, many
> things don't work as most users want.

i manually never touched that file.

> If /etc/permissions.easy does not exist, it will not work.

i don't have /etc/permissions.easy
i searched for permissions.easy in yast, and found /usr/share/permissions/permissions.easy from package "permissions-config"
package "permissions" does not contain any files.

i have installed the following packages with "permission" in their name:
* permissions
* permissions-config
* permissions-doc

only package "permissions-config" has one file in /etc, it is /etc/permissions.local
all the other files are in /usr/share.
these are:
/usr/share/fillup-templates/sysconfig.security
/usr/share/permissions
/usr/share/permissions/permissions
/usr/share/permissions/permissions.easy
/usr/share/permissions/permissions.paranoid
/usr/share/permissions/permissions.secure

> 
> /etc/permissions.easy is part of permissions package, and it contains line:

on my system permissions package has no file at all.
it is version 20200506.1550-14.1

> /bin/su                                                 root:root        
> 4755
> 
> Please try "rpm -V permissions".

this gives zero output.