Unable to authenticate as user 'root' (I have added a password) OR as current user (account has no password due to end user preference)

[Michael Evans]

Binary package hint: gnome-system-tools

Unable to authenticate as user 'root' (I have added a password) OR as current user (account has no password due to end user preference).

The end users in question want one click logins and to not remember passwords. They might be convinced to use literal 'USB Keys' for login if support existed, but that is beyond the scope of this bug.

When using passwd -d (account) to clear the password, sudo, authentication (unlock root privileges) do not work; additionally as root was given a password it should be a user that is allowed to authenticate but there does not seem to be a way of entering that account information (the user list is a drop-down only, no text input).

There are two related bugs here:

1) Unable to authenticate using the root account (when it has a password set)
2) Unable to authenticate using a normal user account (when it has no password)

If the above is intended and not accidental it should be selectable (users should be able to do what they want even if it isn't smart) and/or at minimum tell the user /why/ they can't do what they want and help guide them to fixing it.

ProblemType: Bug
Architecture: i386
Date: Sat Oct 17 14:50:15 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/users-admin
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Alpha i386 (20091017)
Package: gnome-system-tools 2.28.0-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: gnome-system-tools
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
 (gnome-settings-daemon:4789): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:4789): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:4904): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:4889): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (yelp:5011): Yelp-WARNING **: Failed to load config file: No such file or directory

[Milan Bouchet-Valat (nalimilan)]

As you half-guessed, most of what you report here is intentional. Namely:
1) we don't want people to log in as root using GDM - logging through the console could make sense, but never using a GUI, where many issues arise. You should never need do to so, anyway, PolicyKit and sudo/gksu are here for you.
2) we don't want user accounts to stay without password because that can lead to security issues, even if you may argue that a home computer does not suffer from many threats.

Now, there are also bugs that bring you into that situation. First, 2) is not absolutely intended, since we could at least allow people to log in without password locally. That's bug 104957, which you can circumvent at your own risk by replacing 'nullok_secure' in /etc/pam.d/* with 'nullok', meaning empty password will be accepted for all ttys 'not SSH hopefully).

But IMO the best solution would be to allow password-less logins as described at bug 393854, and there's already a graphical way of enabling that in users-admin - the problem is, it's disabled because it lacks support in GDM. If you prefer that way, you can simply adapt /etc/pam.d/gdm as does the patch by adding:
auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
and create group 'nopasswdlogin' so that users-admin works with that feature. Anyway, good luck!

[Michael Evans (mjevans1983)]

The user logged in at the time was NOT root. As I described, I had created a root password (I like su better than sudo -s, and local root login is nicer for servicing a system than the potential alternative of needing to reboot and chroot). It should then be a valid user in the drop-down dialog OR the ability to enter other users should somehow exist.

Additionally not displaying some reason for failure, and worse not clearly explaining the failure to an uneducated home user who 'followed some directions for enabling password-free login' (setting no password) is not a user friendly design.

[Michael Evans (mjevans1983)]

I should clarify, this is an issue I encountered trying to unlock the privileged mode of system administration tasks. As an example, adding/modifying users/groups with the tool found in the system menu. It should be very easy to duplicate this bug on any ubuntu (gnome-desktop based) system. I am unsure if kubuntu or xubuntu desktops are similarly affected.

[Milan Bouchet-Valat (nalimilan)]

> I like su better than sudo -s,
Without more precise reasons for that, please understand we can't take that request into account There are no downsides of using 'sudo -s' versus su.

> and local root login is nicer for servicing a system than the potential alternative of needing to reboot and chroot
why reboot and choot? You can do everything you want using 'sudo -s' and Authentication prompt dialogs. And if you really want a admin-dedicated account, you can create an account only for that, which a secure password, give him admin rights and choose it in the list when authenticating. I guess you didn't get my point because you think the drop-down doesn't work: actually, it will allow you to choose any user, but not root, because it's not supposed to have a password in this design. Just create a normal admin account, and everything will work.

Please don't consider this behavior as a failure. You're not such an "uneducated user" since you managed to create an account without password. No Ubuntu documentation nor any graphical tool allowed you to do so, and there's a reason for that. The only failure here is that described in bug 393854, which is about allowing easy password-less accounts. If you don't want to create a separate admin account, I suggest you apply the method I described in my last comment and that is on that bug report too.

[Michael Evans (mjevans1983)]

Having this behavior isn't in it's self a bug. Not /documenting/ the behavior properly in dialogs related to system administration tools /is/ a bug. Additionally when root ==HAS A PASSWORD== it is a valid account to authenticate against; disallowing that is also a bug.

[Milan Bouchet-Valat (nalimilan)]

Where would we document this? Do you think we should add a bug red warning on every authentication dialog explaining what we don't want users to do?! The right way is to allow password-less accounts to be properly set up, not to explain why we don't allow unwanted configurations to be used.

Anyway, please don't discuss this any longer on that bug report. If you think you can make this policy change, which I doubt, please go and discuss that on an Ubuntu mailing list.

[Michael Evans (mjevans1983)]

While I agree that the correct policy would be to (after a clear warning) allow password-less accounts...

'Documentation' in this case should be a CLEAR error message triggered by this combination of events: Attempting to use the unlocked mode of system administration packages with any account name combined with no entered password. Such a message might state:

"Sorry! Security measures prevent change to the system by accounts that lack passwords. Please (hyperlink this too)change your account password(hyper-linked to local documentation). For more information see (relevant educational link) ."

The linked document MAY (probably should) also document how to do what the user wants -anyway-; if they are able to perform said changes they are likely their system's administrator anyway.)

[Milan Bouchet-Valat (nalimilan)]

That would be a PolicyKit bug. Feel free to provide a patch if you think that feature is worth the pain - or go and discuss that on their mailing list. I don't think anybody else will spend time on that as we generally consider it as bad practice. Again, create a separate admin account. If the admin is smart enough to use 'passwd -d' to remove passwords from accounts, he's surely aware of the obvious fact that you *cannot technically authenticate* when you don't have a password at all.

[David Samuels (davidmsamuels)]

Michael:

I found the same problem with a machine on which Karmic had been "clean-installed" and I, too, like to have a login for root. On another machine, where I had set up a root login previously in Intrepid, the root login is still available after upgrading to Karmic.

[Milan Bouchet-Valat (nalimilan)]

David: what's your problem exactly? You can set up a password for root in Karmic too, it's just that PolicyKit won't allow you to enter the root password to authenticate. I fail to see how upgrading from Intrepid would change that...