Created attachment 1834585 [details] journal Description of problem: It is possible to get through the initial-setup without creating a root user and without assigning a created user to the wheel group. Resulting system has no way to execute superuser commands, access sudo and change any configuration/install packages/package updates and even to properly shutdown the system. Version-Release number of selected component (if applicable): initial-setup-0.3.93-2.fc35 How reproducible: Always Steps to Reproduce: 1. Create a bootable sd card, with eg. sudo fedora-arm-image-installer --image=Fedora-Minimal-35-20211018.n.0.aarch64.raw.xz --resizefs --norootpass --target=rpi4 --media=/dev/mmcblk0 (or without --norootpass, doesn't make difference) 2. Boot the device up 3. Go through the initial-setup, leave the root account disabled, don't set up the created account as an administrator Actual results: System without root and without any user Expected results: Initial-setup shouldn't allow to end with a system without any root access possible. Additional info:
Proposed as a Blocker for 35-final by Fedora user frantisekz using the blocker tracking app because: Not having a root account (or sudo access) available breaks a bunch of release criterions, eg. The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated.
This seems to be an Arm thing only. With x86_64 installation I was not able to get rid of an incomplete G-I-S in any way, which would trigger the described status.
(In reply to Lukas Ruzicka from comment #2) > This seems to be an Arm thing only. With x86_64 installation I was not able > to get rid of an incomplete G-I-S in any way, which would trigger the > described status. I haven't tested the x86_64 yet. But this occurred only when bootting directly from the image and not from the installed system. Also, this is about initial-setup (the cli one), not G-I-S.
My leading theory is that the issue is caused by Initial Setup parsing the kickstart present on the ARM installation image (in /root/anaconda-ks.cfg), which includes the rootpw command. This in turn satisfies the "is there an admin user ?" check: def check_admin_user_exists(self): """Reports if at least one admin user exists. - an unlocked root account is considered to be an admin user - an unlocked user account that is member of the group "wheel" is considered to be an admin user :return: if at least one admin user exists """ # any root set from kickstart is fine if self._rootpw_seen: return True # if not set by kickstart root must not be # locked to be cosnidered admin elif self.root_password and not self.root_account_locked: return True # let's check all users for user in self.users: if not user.lock: if "wheel" in user.groups: return True # no admin user found return False From: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/users/users.py#L371 In this case, _rootpw_seen indicates if the rootpw command has been seen in the input kickstart file - any usage of the rootpw command is sufficient there, including "rootpw --lock". The behavior is fine for the installation usecase (the user might want to deploy a machine not reachable via regular user accounts in an admin capacity) but causes an issue there for Initial Setup running on ARM in reconfig mode - the roopws command used when creating the image ends up in the kickstart Anaconda stores to the image by default. Initial Setup then sees the rootpws command and considers it sufficient for the "is there an admin ?" check, letting users setup an ARM system without any admin users. To fix this issue, I recomend making sure the anaconda-ks.cfg file is not present on the image. This can be achieved by passing the inst.nosave=output_ks to Anaconda at image generation time (for more details see: https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-nosave). Can the image generation tooling running Anaconda do that ? Alternatively making sure the rootpw command is not present in the anaconda-ks.cfg file should also fix the issue, but Anaconda currently has no provisions for filtering what command will and will not be present in the output kickstart, so some later stage of the image build process would have to do that with sed or similar.
In today's Go/No-Go meeting, we agreed: This can be fixed with a reinstall if noticed quickly and is a behavior that existed in previous releases https://meetbot.fedoraproject.org/fedora-meeting/2021-10-21/f35-final-go_no_go-meeting.2021-10-21-17.00.log.html#l-319
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.
So I was hoping we could get this fixed with the slip, but I had to prioritize the blockers and it doesn't look like anyone else got to it :/ It's a bit late now, but I took a look into it, and I think we can at least in theory do what Martin suggests in Oz: https://src.fedoraproject.org/rpms/oz/pull-request/3 submitted as a PR because I'm not 100% confident it a) would work as anticipated or b) be safe, any review appreciated.
So, the PR was merged for Rawhide yesterday, and a build was run. Can someone test an image from today's Rawhide and check whether the kickstart file is gone, and if so, whether that does fix the bug? I'm assuming the Oz from Rawhide is used to build Rawhide images, here. If not, we would I guess need to update Oz for whatever the builders are running to see the change...
(In reply to Adam Williamson from comment #8) > So, the PR was merged for Rawhide yesterday, and a build was run. Can > someone test an image from today's Rawhide and check whether the kickstart > file is gone, and if so, whether that does fix the bug? > The kickstart is still included on the image. Tested Fedora-Minimal-Rawhide-20211027.n.0.aarch64.raw.
Umm. So looking more carefully, I may have patched the wrong place...though I'm not sure what the place I patched is used for, exactly. I can see the other place we might need to touch, I'll send another patch.
https://src.fedoraproject.org/rpms/oz/pull-request/4
OK, that got merged and built a couple of days ago, so once more - does it work better yet?
(In reply to Adam Williamson from comment #12) > OK, that got merged and built a couple of days ago, so once more - does it > work better yet? Kickstart is still included on images from Fedora-Rawhide-20211101.n.0
OK. So, it seems we really are just using the oz package installed on the builders, and the builders are F34. Kevin's gonna help us do a dry run here by updating Koji staging to use a scratch oz build I just did and run an image build on it, that should let us find out if the change worked. If it does, we can do an official update for F35 and F34.
So it looks like we kinda dropped the ball on this. I don't know what happened after the last comment - if we ever built that image or tested it - but the PR eventually got merged and released, and it looks like it actually breaks initial-setup completely, because it assumes the kickstart will be present: https://bugzilla.redhat.com/show_bug.cgi?id=2057600
I'm setting this back to ASSIGNED because we've had to revert the change that was intended to fix it for now. As explained at 2057600, that change stopped initial-setup from running at all. We need to come up with a better fix for this, either by making initial-setup work without a kickstart, or figuring out a different way to fix the problem. I'm also proposing it as an F36 Beta FE - it was an FE for F36 Final, so seems logical.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/636 , marking accepted.
This was nominated in-meeting as a Prioritized Bug and accepted because it is a corner case, but it can lead to a very bad experience for users who encounter it https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-16/fedora_prioritized_bugs_and_issues.2022-11-16-15.05.log.html#l-53
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Can I ask a dumb question here? Well, I'm going to anyway.... What if we just drop the first check, for `self._rootpw_seen`, and rely on `self.root_password and not self.root_account_locked` in all cases?
Bumping the release as the issue happens on f38 too, to prevent auto-closure.
Will take a look next week. :)
(In reply to Martin Kolman from comment #22) > Will take a look next week. :) Any updates, Martin?
(In reply to Ben Cotton from comment #23) > (In reply to Martin Kolman from comment #22) > > Will take a look next week. :) > > Any updates, Martin? Still looking into it, should have something soon. :)
So I've changed Initial Setup to survive running without a kickstart file (/root/anaconda-ks.cfg) being present. That really seems like the best fix right now. PR: https://github.com/rhinstaller/initial-setup/pull/144 Initial Setup scratchbuild with the fix: https://copr.fedorainfracloud.org/coprs/m4rtink/initial_setup_no_kickstart/build/5378430/ If all works fine, then once the Initial Setup PR lands, change mentioned in comment 15 can be applied again and all should be good. :)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
F38 build with the fix: https://koji.fedoraproject.org/koji/buildinfo?buildID=2149824
Tested with Fedora-Workstation-38-20230220.n.0.aarch64.raw.xz on RPi4. Was able to create a user account in initial-setup and then 'su' to the root account once logged into the account that was created. I believe this means the issue is fixed...
er, not necessarily, it's not clear what you did exactly. this is an "adventure choice" bug: it's not that you *always* hit the bug, but that you are allowed to choose a particular adventure which leaves you in a broken situation. what you have to do is see if initial-setup will let you out if you *only* create a non-admin user account. if it blocks you from exiting unless you create an admin user account and/or set a root password, then the bug is fixed. AIUI.
(In reply to Adam Williamson from comment #29) > er, not necessarily, it's not clear what you did exactly. this is an > "adventure choice" bug: it's not that you *always* hit the bug, but that you > are allowed to choose a particular adventure which leaves you in a broken > situation. > > what you have to do is see if initial-setup will let you out if you *only* > create a non-admin user account. if it blocks you from exiting unless you > create an admin user account and/or set a root password, then the bug is > fixed. AIUI. Also of note - the environment must *not* have any kickstarts present in the /root directory. So if you don't have any kickstart in /root and Initial Setup correctly enforces root or admin user to be created, then the issue is fixed. :)
I see this is in the F38 stable repo now. Setting to ON_QA until it's been verified.
I wonder: is this the cause of bug 2175244?
Timings don't seem to match up. The test started failing on Rawhide ten days before the initial-setup-0.3.97-1.fc39 build (to fix this bug) happened.
@fzatlouk or @lbrabec Can you please verify this fix?
Nudged the needinfo'ed folks via email
No, this is still an issue (Fedora-Minimal-38-20230403.n.0.aarch64, initial-setup-0.3.97-1.fc38). You can: - Boot the minimal - Create user, set password, unset administrator rights - Finish initial setup (root is disabled by default, you can leave it be) The following .ks files are present in /root: anaconda-ks.cfg; initial-setup-ks.cfg ; original-ks.cfg . > Also of note - the environment must *not* have any kickstarts present in the /root directory. I'd guess the issue must be solved at our images build process now?
(In reply to František Zatloukal from comment #36) > No, this is still an issue (Fedora-Minimal-38-20230403.n.0.aarch64, > initial-setup-0.3.97-1.fc38). > > You can: > - Boot the minimal > - Create user, set password, unset administrator rights > - Finish initial setup (root is disabled by default, you can leave it be) > > The following .ks files are present in /root: anaconda-ks.cfg; > initial-setup-ks.cfg ; original-ks.cfg . > > > Also of note - the environment must *not* have any kickstarts present in the /root directory. > > I'd guess the issue must be solved at our images build process now? Yes, that is the expectation - the change in Initial Setup i did makes it work correctly if no kickstart file is present. So to make everything work as expected, the image build process needs to make sure no kickstart file is present.
What would be the right component to reassign this (or where to report a different ticket), does anyone know? Where is the (arm) image build process tracked?
Well, the story is all in this bug if you go back in time a bit. The change to remove kickstarts was this one: https://src.fedoraproject.org/rpms/oz/pull-request/4 but after it landed, stuff broke because *this* change (the change to make initial-setup work without kickstarts) hadn't actually landed yet: https://bugzilla.redhat.com/show_bug.cgi?id=2057600 so we had to take it back out again. Now the fix to i-s is really there (supposedly), I guess we can put the oz change back in again.
Well, one thing does concern me: we still build some nightly images for F37, I think, like https://kojipkgs.fedoraproject.org/compose/cloud/Fedora-Cloud-37-20230418.0/compose/Cloud/aarch64/images/ . I *think* the change to oz applies at builder level, which means *all* images we build would stop getting kickstarts, including any images we build for F37 (or F36). CCing nirik for confirmation. If that's the case, we should apply the initial-setup change to at least F37 also before pushing out the oz change.
yes, we make f36 and f37 cloud images and containers via daily cron jobs and ostree installer images every updates push. That said, would any of those be affected? The cloud images shouldn't use initial-setup at all. We don't make raw / generic aarch64 images after release...
Yeah...true, I think it only affects disk images that expect to run i-s on first boot. So...probably it's OK.
Just note that Initial Setup *without* the fix will not working without an input kickstart. On the other hand, it should be possible to add the fix via downstream patch to F37 if really needed.