Bug 856194 - firstboot has to insist the first user is admin when root account is locked
firstboot has to insist the first user is admin when root account is locked
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Sivák
Fedora Extras Quality Assurance
AcceptedNTH
: Reopened
Depends On:
Blocks: F18Blocker/F18FinalBlocker F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-09-11 08:27 EDT by Kamil Páral
Modified: 2012-11-01 16:30 EDT (History)
10 users (show)

See Also:
Fixed In Version: firstboot-18.4-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-01 16:30:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
interface flaw (47.12 KB, image/png)
2012-09-21 12:59 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2012-09-11 08:27:23 EDT
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
Comment 1 Kamil Páral 2012-09-11 08:28:51 EDT
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
Comment 2 Tim Lauridsen 2012-09-12 00:42:46 EDT
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
Comment 3 Kamil Páral 2012-09-12 07:23:16 EDT
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.
Comment 4 Adam Williamson 2012-09-12 15:31:46 EDT
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.
Comment 5 Fedora Update System 2012-09-12 15:42:11 EDT
firstboot-18.3-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/firstboot-18.3-1.fc18
Comment 6 Adam Williamson 2012-09-12 17:27:09 EDT
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.
Comment 7 Fedora Update System 2012-09-13 12:44:12 EDT
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).
Comment 8 Kamil Páral 2012-09-18 08:55:05 EDT
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.
Comment 9 Adam Williamson 2012-09-18 15:11:25 EDT
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.
Comment 10 Fedora Update System 2012-09-18 16:00:39 EDT
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.
Comment 11 Kamil Páral 2012-09-19 04:15:00 EDT
(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.
Comment 12 Martin Sivák 2012-09-19 07:41:06 EDT
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.
Comment 13 Fedora Update System 2012-09-19 07:45:02 EDT
firstboot-18.4-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/firstboot-18.4-1.fc18
Comment 14 Fedora Update System 2012-09-20 01:58:41 EDT
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).
Comment 15 Kamil Páral 2012-09-21 12:59:01 EDT
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.
Comment 16 Kamil Páral 2012-09-21 12:59:25 EDT
Created attachment 615518 [details]
interface flaw
Comment 17 Martin Sivák 2012-09-24 06:07:10 EDT
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..
Comment 18 Adam Williamson 2012-09-28 18:20:37 EDT
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).
Comment 19 Martin Sivák 2012-10-01 06:10:02 EDT
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
Comment 20 Kamil Páral 2012-10-02 09:33:13 EDT
(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.
Comment 21 Kamil Páral 2012-10-03 09:06:59 EDT
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.
Comment 22 Adam Williamson 2012-10-05 03:17:10 EDT
Kamil: I'm pretty sure, on my test, I could not log in as root with an empty password.
Comment 23 Kamil Páral 2012-10-05 04:13:03 EDT
(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.
Comment 24 Martin Sivák 2012-10-05 05:51:57 EDT
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?
Comment 25 Kamil Páral 2012-10-05 07:03:45 EDT
Yes, even though the checkbox is disabled and unchecked, the new user is in @wheel.
Comment 26 Kamil Páral 2012-10-08 10:25:57 EDT
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.
Comment 27 Adam Williamson 2012-10-09 23:54:09 EDT
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.
Comment 28 Adam Williamson 2012-10-12 16:11:02 EDT
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...
Comment 29 Adam Williamson 2012-10-12 16:12:33 EDT
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.
Comment 30 Martin Sivák 2012-10-15 08:30:05 EDT
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.
Comment 31 Alexander Larsson 2012-10-16 02:30:26 EDT
gtk3-widget-factory shows the checkbox in all the states, including !sensitive && active. It seems to work here.
Comment 32 Cosimo Cecchi 2012-10-17 12:04:41 EDT
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
Comment 33 Adam Williamson 2012-10-17 18:45:15 EDT
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?
Comment 34 Adam Williamson 2012-10-17 19:35:55 EDT
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.
Comment 35 Adam Williamson 2012-10-17 19:53:39 EDT
Filed https://bugzilla.redhat.com/show_bug.cgi?id=867653 for the adwaita bug.
Comment 36 Fedora Update System 2012-10-18 07:52:16 EDT
firstboot-18.5-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/firstboot-18.5-1.fc18
Comment 37 Fedora Update System 2012-10-18 11:27:25 EDT
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).
Comment 38 Adam Williamson 2012-10-26 16:24:02 EDT
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.
Comment 39 Adam Williamson 2012-10-31 15:53:58 EDT
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.
Comment 40 Martin Sivák 2012-11-01 06:13:31 EDT
Adam, 18.5 already reached the point where I was able to propose it for stable. It should get there any time now.
Comment 41 Adam Williamson 2012-11-01 16:30:48 EDT
Update went stable, closing.

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