0

On a SLES 15 SP1 system, I've added a user to the wheel group:

wheel:x:1003:joeuser 

however, when joeuser logs in as themselves, then tries to su (to become root), they are asked for their password. Why could that be happening?

Here is /etc/pam.d/su:

#%PAM-1.0 auth sufficient pam_wheel.so trust auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so 
4
  • 2
    I don't know about PAM, but on the systems I'm used to, membership in the wheel group grants you access to su, but you still have to know the password of the user you are impersonating. I haven't really seen su being set up to grant passwordless access to another user's account (from non-root users). I would use doas or sudo for that. Commented Dec 17, 2024 at 10:01
  • @Kusalananda: Typically, when you're in the wheel group, and you're already logged in as joeuser, you can su without further authenticating. Also, clarified that I don't mean becoming another non-root user, just plain su to be root (although impersonation also works without authentication, and you don't have to know their password). Commented Dec 17, 2024 at 10:05
  • Is that the only wheel group you have? (I'd expect it to have a lower GID...) Do you know for sure that your su implementation actually uses PAM? If it does, did you update both pam.d/su and pam.d/su-l for the two different su invocations? Commented Dec 17, 2024 at 10:52
  • @grawity: It is, and I am miffed by the high gid as well. On a very similar machine I see a gid of 497. I did add the group manually. Commented Dec 17, 2024 at 13:02

1 Answer 1

1

How are you testing things? Are you logging in as joeuser directly, or are you logging in as root (or another user) and then su-ing to the joeuser account?

I was trying to reproduce the behavior you've described in a SLES container, and I successfully (?) ran into the same problem:

testuser@714eeb148216:~> su Password: 

I turned on debug output for the pam_wheel module...

auth sufficient pam_wheel.so trust debug 

...and noticed I was hitting this error:

pam_wheel(su:auth): who is running me ?! 

And that's because in my container environment I was missing the utmp file (/run/utmp, aka /var/run/utmp). This is used by pam_wheel to identify the user who originally logged in on the current tty. The file is populated by the login program, and it must exist first.

Once I (a) created an empty /run/utmp file and then (b) arranged for login to run on a fake pty device, I was able to log in as a test user and su without a password:

testuser@714eeb148216:~> su 714eeb148216:/home/testuser # 

Running su - would still fail until I also updated /etc/pam.d/su-l.

However: if I logged in as root, and then switched to an unprivileged user:

714eeb148216 login: root Password: Directory: /root Tue Dec 17 11:43:14 UTC 2024 714eeb148216:~ # groups root 714eeb148216:~ # su - testuser 

I will again get prompted for a password:

testuser@714eeb148216:~> su Password: 

Because:

pam_wheel(su:auth): Access denied to 'root' for 'root' 

pam_wheel sees that root was the user that originally logged in on the terminal, so even though I am running su as the testuser user, pam_wheel is basing decisions on the group membership of root.


You can modify this behavior so that pam_wheel does not consult /run/utmp (and instead uses the uid of the calling process to determine permissions) with the use_uid option; if I modify /etc/pam.d/su like this:

auth sufficient pam_wheel.so trust use_uid debug 

Then the above process works as expected.

2
  • This worked, but one doesn't need the debug modifier. Commented Dec 17, 2024 at 13:09
  • That’s true, but the additional diagnostics were both minimal and useful. Commented Dec 17, 2024 at 13:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.