'su' command doesn't ask for password in fedora minimal template (qubes-core-agent-passwordless-root)

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.

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

Actually that is expected behavior.

Replacing passwordless root access with Dom0 user prompt

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.

Nice finding.

But, I am genuinely interested in to hear first is su genuinely is expected to ask for a password or not in Qubes.

After that, everything will be easier, I think.

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

I know, but I’m speaking about the Qubes concept. If I’d found what you did, I’d actually ask how su 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, @rustybird su 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.

It is indeed not a problem that qubes-core-agent-passwordless-root makes su passwordless :wink:

That’s normal in dom0, although I guess it could be changed.

1 Like

Thanks. It is rather worthless, because once in dom0 we already can do whatever we want with VMs as user.

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.

1 Like

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.

The solution for me:

rm su
ln -s su.qubes su

I should probably create a bug report.

1 Like

I can reproduce this. Updating replaces the symlink with the regular file from util-linux.

Please do!

1 Like