Description of problem: If I install Fedora 40 Server and only enable root account in anaconda, I can't then log in as root through Cockpit web admin interface. The web UI says "Wrong user name or password". The journal says: Mar 13 12:26:02 localhost.localdomain cockpit-session[1131]: pam_listfile(cockpit:auth): Refused user root for service cockpit This is something that QA test cases suggest that it should work, but perhaps we just need to update our instructions. Either way, after talking to Stephen Gallagher, he asked me to file this so that server folks can look at it. Stephen also said: > I’d expect it to fail in the “account” step in PAM if it was an access-control check So, is this intentional or a bug? I checked Fedora 38 and 39 Server, it behaves the same. Version-Release number of selected component (if applicable): cockpit-311-1.fc40.x86_64 pam-1.6.0-2.fc40.x86_64 Fedora-Server-dvd-x86_64-40_Beta-1.2.iso How reproducible: always Steps to Reproduce: 1. start Fedora 40 Server DVD install 2. only enable root account, don't enable regular account 3. install 4. after booting the installed system, connect to the web address printed in the console, try to log in as root 5. login fails
Created attachment 2021420 [details] journal.txt
Created attachment 2021421 [details] rpm-qa.txt
Proposing for a blocker discussion, because Stephen Gallagher asked me to do it :-)
Also, if I enable ssh in anaconda, logging in as root through ssh works fine. It's just Cockpit that's "affected".
Hello Kamil, indeed root login is *not* supposed to work by default. See https://cockpit-project.org/blog/cockpit-280.html This is similar how ssh disables it by default. You can edit /etc/cockpit/disallowed-users , but we don't recommend that. (In fact, I'd recommend to never have a root password in the first place..)
For the record, I consider this a conditional violation of the Beta Release Criterion: "It must be possible to log in to the default Cockpit instance and use it to: *) View the system's logs *)View the system's running services" with the condition being that the user has elected to create only the root account on the system. Kamil suggested that we should treat this as a potential Final blocker rather than Beta under that condition, which I agree with.
(In reply to Martin Pitt from comment #5) > Hello Kamil, > > indeed root login is *not* supposed to work by default. See > https://cockpit-project.org/blog/cockpit-280.html This is similar how ssh > disables it by default. You can edit /etc/cockpit/disallowed-users , but we > don't recommend that. (In fact, I'd recommend to never have a root password > in the first place..) For SSH, there's an option in the anaconda installer to specifically permit this (for this exact case: only a root user is installed). While I agree that root logins are generally a bad idea, if we're allowing them to set this configuration up in anaconda, we should not subsequently be preventing them from logging in.
> Proposing for a blocker discussion This behavior changed one and half years ago so I assume it is in at least two versions of Fedora maybe even 3. (As Kamil mentions "I checked Fedora 38 and 39 Server, it behaves the same."). Does it make sense to propose blocker for something that hasn't changed since F37? But I agree that it should be possible for user to log in when they only create root, I just don't think blocker at this stage is relevant. > For SSH, there's an option in the anaconda installer to specifically permit this (for this exact case: only a root user is installed). Should it then be RFE for Anaconda?
(In reply to Matej Marušák from comment #8) > > Proposing for a blocker discussion > > This behavior changed one and half years ago so I assume it is in at least > two versions of Fedora maybe even 3. (As Kamil mentions "I checked Fedora 38 > and 39 Server, it behaves the same."). Does it make sense to propose blocker > for something that hasn't changed since F37? Just because we didn't notice it doesn't mean it isn't violating the criteria. And it's a *proposed* blocker; the review process will decide if it's accepted. > But I agree that it should be possible for user to log in when they only > create root, I just don't think blocker at this stage is relevant. > > > For SSH, there's an option in the anaconda installer to specifically permit this (for this exact case: only a root user is installed). > > Should it then be RFE for Anaconda? That's one approach that we can take, sure. I'd like to point out, though, that Cockpit is ALSO making this decision at the wrong PAM stage. For proper auditing, it needs to happen at the "account" stage (aka Authorization), rather than the "auth" (aka Authentication) stage. If it fails "auth", it means the user provided invalid credentials. If it fails "account" it means an authenticated user was denied access.
Here's the criterion link: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria#Cockpit_management_interface The criterion doesn't say it has to work with root, and it doesn't say that some prerequisite steps can't be required (i.e. creating a regular user). Also the fact that it's not a recent regression makes it less likely to be accepted, IMO. But Stephen wants to discuss it, and that's the purpose of a blocker review, so let's discuss it. The blocker review discussion ticket is here: https://pagure.io/fedora-qa/blocker-review/issue/1519 (you can also provide your thoughts here, thanks)
> I'd like to point out, though, that Cockpit is ALSO making this decision at the wrong PAM stage Thanks for pointing out! I fixed that in https://github.com/cockpit-project/cockpit/pull/20165
Discussed during the 2024-03-18 blocker review meeting: [1] The decision to classify this bug as a RejectedBlocker (Final) was made: "We all agree it can be argued as a conditional violation of the criteria, but our subjective opinion (as is required for conditional violations) is that it's not a serious enough case to count as a blocker. it has been the case for several releases without major complaints." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-03-18/f40-blocker-review.2024-03-18-16.01.log.html
(In reply to Stephen Gallagher from comment #9) > I'd like to point out, though, > that Cockpit is ALSO making this decision at the wrong PAM stage. For proper > auditing, it needs to happen at the "account" stage (aka Authorization), > rather than the "auth" (aka Authentication) stage. If it fails "auth", it > means the user provided invalid credentials. If it fails "account" it means > an authenticated user was denied access. So this problem has already been resolved. @sgallagh what do you want to do next with this bug? Do you want to ask anaconda to make that "allow SSH for root" option to also allow cockpit login? (Ideally rewording the option a bit). Feel free to take this bug and reassign it, specify what you want to see, etc. Thanks.
Yes, I'll reassign it to Anaconda. I don't want to dictate a specific UX here, but I think there needs to be at least some minimal information given to the user if their current selections would disallow them from logging in remotely, ideally with the option to re-enable that functionality for Cockpit.
> For SSH, there's an option in the anaconda installer to specifically permit this (for this exact case: only a root user is installed). Just for the record: The cockpit team *does not condone* this in either ssh or cockpit. Anaconda can technically do it of course, but that is an unilateral decision, not an agreement. It would IMHO be better to change Anaconda to either just never set a root password in the first place, or at least point out that you can't use it for remote (SSH, cockpit) logins.