Description of problem: root user is now disabled by default, unless the user provides a password in the installer. But when firstboot creates a new user, the "Admin user" checkbox is unchecked by default. That means you will end up with a system without root access and without sudo access. You can't install new packages or updates, nothing. It's non-trivial to fix the situation (you have to boot to runlevel 1). Firstboot has to insist that the first user created is an admin user (in the wheel group), if root account is locked. Flipping the default state of the checkbox (to checked) helps a bit, but it's not the right solution. Firstboot shouldn't allow us to disable this checkbox until at least one admin user is created. Version-Release number of selected component (if applicable): firstboot-18.2-2.fc18.x86_64 F18 Alpha RC2 How reproducible: always Steps to Reproduce: 1. install Fedora, don't fill in root password 2. create new user in firstboot, leave all defaults (no admin rights) 3. you can't administer your system
Let's discuss whether this is an Alpha blocker. We have a criterion that is broken if you keep all the defaults and just perform the installation: " The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops " https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
One could argue then it should not be possible to opt out the Admin User, if no root pw is set. It should be grayed out and always selected. IMHO
I might not attend today's blocker bug meeting. My vote is definite +1 NTH, and a mild +1 blocker. The reasoning is that the default choices now lead up to no root and no admin user, rendering the system barely usable. OTOH this flaw is not critical, the worst thing that can happen is that people will re-install again and create an admin user this time. This is Alpha, such issues are a bit expected.
Discussed at 2012-09-12 blocker review meeting. This was rejected as blocker with the general agreement that Alpha testers should be able to recover from such a situation and/or read the instructions on how to avoid it. It was accepted as NTH, however, and a fixed firstboot build will be available soon.
firstboot-18.3-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firstboot-18.3-1.fc18
I built a live image with the fixed firstboot. Tested that the checkbox is checked by default, and this works: it does give the user admin privs. Setting VERIFIED.
Package firstboot-18.3-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firstboot-18.3-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13896/firstboot-18.3-1.fc18 then log in and leave karma (feedback).
The previous fix was OK for Alpha (and maybe Beta). Now proposing as F18 final blocker. Firstboot should ensure the checkbox can't be disabled for the first created user account.
Well, it might want to adjust behaviour depending on whether the root account is accessible or not. Though I'm not entirely sure it can know that without a hint from anaconda, I'm uncertain of the mechanics.
firstboot-18.3-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #9) > Well, it might want to adjust behaviour depending on whether the root > account is accessible or not. Though I'm not entirely sure it can know that > without a hint from anaconda, I'm uncertain of the mechanics. You are right, if root account is enabled we don't have to insist on another admin user. Because firstboot already runs with admin privileges, it can easily check using "passwd -S root" whether root account is locked or not and adjust its behavior.
Firstboot now uses libuser to check if root is disabled and wheel group is empty. It then forces the new user to be admin. The fix went to firstboot-18.4-1.
firstboot-18.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firstboot-18.4-1.fc18
Package firstboot-18.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firstboot-18.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14392/firstboot-18.4-1.fc18 then log in and leave karma (feedback).
firstboot-18.4-1 works as expected, except for a minor flaw - if it enforces an admin user, it actually looks like it prohibits you achieving it. The checkbox is disabled, which is fine, but it is unchecked. Which communicates "your user won't be an admin user and you can do nothing about it". So please, when in the admin enforcing mode, either make the checkbox completely disappear, or disable it AND uncheck it.
Created attachment 615518 [details] interface flaw
The checkbox is supposed to be checked and disabled: if self.admin.userIsLocked(root) and len(wheel_members) == 0: self.is_admin.set_active(True) # this user will be admin by default self.is_admin.set_sensitive(False) # and user cannot change this So there must be something weird going on as the set_sensitive call was obviously executed..
I just did a test install with smoke3, netinst, so it got firstboot 18.4 (checked from a console with rpm -q). This seemed to be completely broken. I didn't set a root password during install, but in firstboot, the box was enabled and was not checked. I decided to leave it unchecked and complete firstboot, to see if it was actually selected but showing as unchecked, but no: the user created was not part of the admin group. So it results in a broken system (no root password, no admin user).
That is weird, it behaves differently from what Kamil saw. Can you please go to single mode and try the following in python? import libuser admin = libuser.admin() wheel = admin.enumerateUsersByGroup("wheel") root = admin.lookupUserById(0) print wheel print admin.userIsLocked(root) Thanks
(In reply to comment #19) I repeated F18 Alpha netinst install, so that I got firstboot-18.4-1.fc18. > print wheel [] > print admin.userIsLocked(root) 1 The checkbox is still disabled and unchecked. But the newly created user is in @wheel.
I installed F18 Beta TC1, without setting root password, and the checkbox is enabled and unchecked by default. And I know why. Because the root account is NOT locked, it has an empty password instead. That is bug 859069, but it applies for Live installations as well.
Kamil: I'm pretty sure, on my test, I could not log in as root with an empty password.
(In reply to comment #22) > Kamil: I'm pretty sure, on my test, I could not log in as root with an empty > password. Well, passwd -S root told my "password empty" and admin.userIsLocked(root) returned 0. But with F18 Beta TC2 Live, the root password is locked again, so we're back in comment #15.
Ff you look at comment #17 then that probably means there is a bug in Gtk.. does #20 still apply? Is the new user in @wheel?
Yes, even though the checkbox is disabled and unchecked, the new user is in @wheel.
Today I installed F18 Beta TC2 Live (x86_64) again, and root password is empty! (and therefore comment 21 applies again). I wonder how is that possible. I used a USB stick created by livecd-iso-to-disk.
I just tested from Beta TC3 DVD. I didn't set a root password. firstboot showed the checkbox greyed out and un-selected, but the user created was actually an admin user (in the 'wheel' group, can sudo). This is with 18.4.
maybe we should push 18.4 at this point, as we've included it in the last few composes without any obvious car crashes, and I can't reproduce the absolute failure case I had in comment #18 any more...
well, it seems now at least kamil and I are in agreement, when the root account is locked, firstboot looks like it's not creating an admin user but actually is. i dunno if we should wait for that to be fixed before pushing or just push now.
I think the unchecked and disabled checkbox is a bug somewhere else. The code in firstboot is clear here (#17). We should probably test the Gtk itself as they have had UI bugs before during this release.
gtk3-widget-factory shows the checkbox in all the states, including !sensitive && active. It seems to work here.
The UI bug described here is actually a bug in the Adwaita gtk2 theme which I now fixed upstream [1]. Will build an updated package soon. [1] http://git.gnome.org/browse/gnome-themes-standard/commit/?id=f9b39e206a25da630506aa160d6a66d236b07616
Awesome. So I think we should ignore that cosmetic bug and check that both cases work as intended in 18.4: admin user creation is forced when the root account is locked, and not forced when the root account is not locked. If those two scenarios are good we should push 18.4 stable and close this bug. Sound good?
OK, I just tested every variation of this with TC4 desktop: firstboot 18.4 behaves correctly in each case. If root PW is set during install, the checkbox is active and unchecked by default; both leaving it unchecked and checking it produce the expected behaviour. If root PW is unset during install, the checkbox appears greyed out and unchecked, but we now know that's the adwaita bug, and the behaviour is correct (the user is an admin). So I'm pretty confident we can say this bug is fixed, and file a new one on adwaita to track that issue. Setting VERIFIED, will add +1 karma on the update.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=867653 for the adwaita bug.
firstboot-18.5-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firstboot-18.5-1.fc18
Package firstboot-18.5-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firstboot-18.5-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16399/firstboot-18.5-1.fc18 then log in and leave karma (feedback).
Proposing as NTH for Beta. I assumed this would have gone stable long ago, but it didn't. We definitely should have this in for Beta. Going back to 18.3, which does not ensure an admin user is created when root account is locked, would suck.
Discussed at 2012-10-31 NTH review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . Accepted as NTH - with the planned change to enforce root PW in all cases this becomes almost a null issue, but it's still possible that might get backed out, and we've been testing 18.4/18.5 for so long it's probably safer to take it than 18.3 at this point.
Adam, 18.5 already reached the point where I was able to propose it for stable. It should get there any time now.
Update went stable, closing.