Bug 2015508 - anaconda allows to install a system without an admin user
Summary: anaconda allows to install a system without an admin user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vladimír Slávik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F35FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2021-10-19 11:53 UTC by Kamil Páral
Modified: 2021-11-01 15:05 UTC (History)
10 users (show)

Fixed In Version: anaconda-35.22.2-3.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-28 18:28:10 UTC
Type: Bug


Attachments (Terms of Use)
bug demonstration video (1.90 MB, video/webm)
2021-10-19 11:54 UTC, Kamil Páral
no flags Details
insufficient accounts in anaconda (98.48 KB, image/png)
2021-10-19 18:37 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2021-10-19 11:53:39 UTC
Description of problem:
Anaconda is supposed to make the user either set up a root password, or create an admin user. However, a flaw in its logic allows to perform an installation which has neither. The resulting system then can't be maintained, because there is no way to get admin privileges.

This affects all installer and Live images (e.g. Everything netinst, Server DVD, KDE Live) except Workstation Live (where user creation is not available in anaconda at all, and everything is handled in gnome-initial-setup during the first boot).

Version-Release number of selected component (if applicable):
anaconda-35.22.2-2.fc35

How reproducible:
always

Steps to Reproduce:
1. boot the installer 
2. set up the root account, i.e. select a password
3. create a regular user (keep all defaults, including not setting it as admin)
4. change up your mind and disable the root account
5. start the installation
6. try to get root privileges in the installed system, you can't

Additional info:
At least for the KDE Live case, this problem should be mitigated by the initial-setup, which should detect that there's no admin user present and force the user to create one. However, that detection doesn't occur properly (which is probably very similar or the same problem as in bug 2015490), and initial-setup immediately exits after start.

Comment 1 Kamil Páral 2021-10-19 11:54:14 UTC
Created attachment 1834614 [details]
bug demonstration video

Comment 2 Kamil Páral 2021-10-19 11:55:12 UTC
Proposing for a blocker discussion, similarly to the proposed bug 2015490.

Comment 3 Lukas Ruzicka 2021-10-19 12:54:36 UTC
Yes, I can reproduce this behaviour.

Comment 4 Vladimír Slávik 2021-10-19 13:21:39 UTC
Ditto.

I did a quick check and it has been in 34 too so it's not the redesign. In fact I am almost certain that this was the same even before we started with the D-Bus thing some 6 Fedoras back or so.

The mechanism is:
- The root + user spokes are mandatory (must be completed) if there is no admin user
- The criterion for an admin user is that it exists, has password and is unlocked (simplified)
- This together means that an enabled root or created admin user make both spokes no longer mandatory = completion does not matter
- The criterion for completion of the root spoke is that the root password is set.

The last point is where the error is, the spoke is mandatory b/c no admin, but it's finished because root has password, even if locked.

Strictly speaking, the redesign made the locked root's password invisible, but it's wrong anyway so let's fix it.

Comment 5 Adam Williamson 2021-10-19 15:15:57 UTC
-4 (blocker) +4 (FE) in https://pagure.io/fedora-qa/blocker-review/issue/557 , marking acceptedFE / rejectedblocker.

Comment 6 Vladimír Slávik 2021-10-19 18:06:37 UTC
Looking at this, the problem is a bit deeper. An easy, quick, and dirty fix is a one liner. However the real problem here is that there is an ambiguity: If no administrator exists, that can be fixed in two spokes at once: root and user. Which one should the user pick, why, and how do we signal it?

Comment 7 Vladimír Slávik 2021-10-19 18:09:07 UTC
Sorry, that got lost somehow.

Comment 8 Kamil Páral 2021-10-19 18:37:05 UTC
Created attachment 1834742 [details]
insufficient accounts in anaconda

> If no administrator exists, that can be fixed in two spokes at once: root and user. Which one should the user pick, why, and how do we signal it?

Perhaps the same way you do it already in anaconda in a more regular workflow (see the attachment)? Yes, it's not ideal, but using the same approach in both cases makes sense, and can be improved in the future.

Comment 9 Adam Williamson 2021-10-19 18:38:02 UTC
I think this used to be indicated by both spokes being 'uncompleted', but if the condition was satisfied in either, both got marked as completed?

It's a tricky problem, not just because we have to indicate "you have to achieve some condition that can potentially be done from either of these two spokes", but also "you could potentially 'complete' either spoke without actually achieving the condition"...

Comment 10 Adam Williamson 2021-10-21 23:55:56 UTC
Note we slipped Final today, so we do have a window to fix this if we can get a sufficiently safe fix in the next few days.

Comment 11 Vladimír Slávik 2021-10-25 08:55:11 UTC
Please define sufficient? If the fix prevents starting an installation that yields no admin, is that enough?

Comment 12 Kamil Páral 2021-10-25 09:25:57 UTC
Answering on behalf of Adam - This bug has been rejected as a blocker, and therefore we'll accept a fix only if the fix seems trivial enough, sp that it won't be likely to break other stuff. That means a complex patch which changes too many places would likely be rejected, a simple "few-liner" would get pulled in through the freeze.

Comment 13 Vladimír Slávik 2021-10-25 12:05:52 UTC
PR: https://github.com/rhinstaller/anaconda/pull/3665

Comment 14 Adam Williamson 2021-10-25 15:55:21 UTC
yeah, "sufficiently safe" means "improves the situation with a small and easily reviewable/testable change", ideally.

Comment 15 Fedora Update System 2021-10-25 18:22:32 UTC
FEDORA-2021-97506f4570 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-97506f4570

Comment 16 Kamil Páral 2021-10-26 07:32:51 UTC
(In reply to Fedora Update System from comment #15)
> FEDORA-2021-97506f4570 has been submitted as an update to Fedora 35.
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-97506f4570

The fix works correctly, it doesn't let me start the installation without an admin user.

Comment 17 Fedora Update System 2021-10-26 15:42:33 UTC
FEDORA-2021-97506f4570 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-97506f4570`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-97506f4570

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2021-10-28 18:28:10 UTC
FEDORA-2021-97506f4570 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.