In Fedora’s minimal template, the su command works without prompting for a password.
Expected behavior:
The su command asks for a password.
Actual Behavior:
The su command does not ask for a password. That being said, sudo su works as expected.
I did a little research on pam files and found some interesting behavior when changing these files.
Firstly, after installing the qubes-core-agent-passwordless-root package, the line auth sufficient pam_succeed_if.so use_uid user ingroup qubes appears in the /etc/pam.d/su and /etc/pam.d/su.qubes files, when commenting this line in either of the two files, the other automatically accepts this comment. Also, if I comment out this line, then su now asks for a password, and sudo su works as it should.
To be honest, I’m confused. How do I get su to work with password prompt like in fedora-full? And what to do with these pam files, they do not correspond to the alternative installation in fedora-full.
Full contents of /etc/pam.d/su and su.qubes. They are the same.
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
# {{ Qubes specific modifications begin here
# Prevent su from asking for password
# (by package qubes-core-agent-passwordless-root).
auth sufficient pam_succeed_if.so use_uid user ingroup qubes
# }} Qubes specific modifications end here
auth substack system-auth
auth include postlogin
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session include postlogin
session optional pam_xauth.so
This is not the expected behavior. In the fedora-36 template, su asks for the password. And this line is not added to pam.d/su, only to su.qubes. The package qubes-core-agent-passwordless-root gives access to sudo , without using qvm-run -u root, as well as sudo su. Normal su must ask for a password.
Ah, sorry, now I see what you mean. I don’t use fedora-36 and never use su, so it never occurred to me, although I’d expect to work for su as well cause it doesn’t matter as I see it…
I just checked in fedora-36 that if you remove the package qubes-core-agent-passwordless-root and install it again, the problem reproduces the same way and now su does not ask for the password. The package qubes-core-agent-passwordless-root somehow breaks the password request in su.
The sudo su and su commands differ in that su asks for the root password because it switches you to root. Sudo, on the other hand, executes commands with root privileges and asks for the user password instead of root. The qubes-core-agent-passwordless-root package is missing in the Qubes template minimal, which means that it is not possible to access sudo privileges from the console or to switch to root. Only through dom0 with qvm-run -u root 'appvm' 'app'. After installing qubes-core-agent-passwordless-root sudo does not ask for a password, but su must still ask for a password, at least in a fedora installation.
It shouldn’t, and at least for the latest unmodified fedora-36 and fedora-37 templates it doesn’t.
When qubes-core-agent-passwordless-root is installed (as it is by default in the full templates), /etc/pam.d/su is supposed to be a symlink to /etc/pam.d/su.qubes. I’m guessing your fedora-36 template is in a broken state where this is not the case - maybe after many upgrades?
I just checked in the new fedora-36, and yes, it is true that it is now a symlink. After installing qubes-core-agent-passwordless-root the symlink is created lrwxrwxrwx 1 root su -> /etc/pam.d/su.qubes.
But now su also does not ask for the password in the new fedora-36 installation, in the old broken installation (as you claim) where there is no symlink, su works with a password request. If you recreate the pam.d/su file without the auth sufficient pam_succeed_if.so use_uid user ingroup qubes line and without the symlink, this solves the problem and su now asks for a password, as it should. If you leave the symlink, then how do you solve the problem with su asking for the password?
In fact, I’m not even sure now if this is a problem or not.
I know, but I’m speaking about the Qubes concept. If I’d found what you did, I’d actually ask howsu asks for password. I hope I cleared my position in this and where my confusion came from.
@rusty confirmed this
It is a problem, but with fedora-36 and not minimal, hahah, at least in your case
Also, @rustybirdsu also asks for a password in dom0 in my case.
It turns out that pam.d is correct when there is a su > su.qubes symlink. This line in the file is responsible for su without a password, if you comment it out, it will ask for the password su.
# {{ Qubes-specific modifications start here.
# Disallow su to ask for the password
# (by the qubes-core-agent-passwordless-root package).
auth sufficient pam_succeed_if.so use_uid user ingroup qubes
# }} Qubes-specific modifications end here
Apparently, my problem was that I assumed this line shouldn’t be there originally, since my template didn’t have a symlink (freshly installed qubes). At least I came to that conclusion based on what @rustybird said and freshly installed fedora-36.
And also, needlessly doing stuff in dom0 as root has a history of causing odd file permission problems (theoretically less so since R4). IIRC that’s the original motivation for why long root shell sessions such as via su are discouraged in dom0, and prefixing individual commands with sudo as needed is preferred. And there’s always sudo -s for when you really do want a root shell.
I tried to figure out the cause of the symlink failure and even reinstalled qubes completely on the test computer. So, the default template when installing qubes and the default template loaded with qubes-dom0-update qubes-template-fedora-36 have a symlink. As soon as I completely update the system with dnf up -y, the symlink disappears.
