Ubuntu

No administrative actions possible (password refused) after enabling passwordless login

Reported by Heiner Geisenberg on 2011-10-26
104
This bug affects 17 people
Affects Status Importance Assigned to Milestone
accountsservice (Ubuntu)
High
Unassigned
gnome-control-center (Ubuntu)
High
Unassigned
gnome-system-tools (Ubuntu)
High
Unassigned
lightdm (Ubuntu)
High
Unassigned

Bug Description

If I choose not to have a password for my operating account, every operation fails if it needs root access. Reproducible even on a newly set up machine. See: http://ubuntuforums.org/showthread.php?t=1862543

Release: 11.10

Cause: The password is cleared to be empty, and this prevents authentification for many admin tasks for security reasons. However, the user only needs to be added to the "nopasswdlogin" group, to enable passwordless login with gdm (and any other DM that ships with a corresponding "auth sufficient pam_succeed_if.so user ingroup nopasswdlogin" configuration).

Fix:
 * lightdm to add pam rule
 * account managing tools not clearing password but only adding user to
   "nopasswdlogin" group

Steps to reproduce:
1. Install Ubuntu 11.10 as normal. During installation, when you are asked to choose a password, enter one, since the installation can not continue if you do not do so.
2. Boot the newly installed system and log in as usual.
3. Choose "System Settings" from the launcher on the left and open "User Accounts".
4. In the User Accounts window, click on Unlock at the top right of the dialog. Enter your user password when prompted.
5. Click on the four dots next to the "Password" label to change your password.
6. Select "Log in without a password" from the dropdown box. Close the window.
7. Try to perform an action requiring administrative privileges. For example, try running "sudo apt-get update" from a terminal.

Expected behavior:
sudo should require the user's password and accept it, or proceed without requiring any password altogether.

Actual behavior:
sudo requires the user's password and does not accept it (since it is set to an empty string in /etc/shadow).

Further notes:
After disabling the password request at login, the /etc/shadow file related to the test user account I created looked like this:
test::15283:0:99999:7:::
This shows that the password hash is made completely empty; that conflicts with the policies listed in /etc/sudoers, which require a password to be given in order to perform
administrative actions.

Workaround:
-If you can not perform administrative actions but can still login without a password, open a terminal and type "passwd". This command should prompt you for a new password and change it without any problems.
-If you can not login, you can reset your password by booting into recovery mode and changing it there. Follow the instructions at <http://psychocats.net/ubuntu/resetpassword>.

You may also choose to use a password for your account and to enable autologin at the same time. This choice will enable you to benefit the advantage of not entering a password at boot time with the security of Ubuntu requiring your password when attempting to perform privileged actions. Of course, this helps when you are the only desktop user or the primary one.

Alessandro Menti (elgaton) wrote :

Some quick notes:
-the check for empty passwords and the alteration of the sudoers file, if *really* required since it's a security risk, should be done in the installer and in the passwd program;
-otherwise, a simple way to prevent null passwords to be used (the most straightforward way) is to alter the PAM configuration files (see <http://www.cyberciti.biz/tips/linux-or-unix-disable-null-passwords.html>).

affects: ubuntu → ubiquity (Ubuntu)
affects: ubiquity (Ubuntu) → ubuntu
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed
Joseph Harrietha (nictrasavios) wrote :

Security isnt really a concern here. If we choose to have no password, we should have no penalty for doing so. There are many reasons for doing it, some as valid as the "security risk"

Personally, I believe the whole security thing is overrated, and if I'm wrong, then let my unprotected computer bear the consequences when virtual demons invade it. Its our choice, and giving us advice on how to not have a blank password does not solve this bug.

So yes, the check is "*really*" required, it should be something done automatically every time passwd is called, or /etc/shadow is updated.

Alessandro Menti (elgaton) wrote :

Actually, leaving any user account that can sudo to root without a password leaves the machine potentially open to intruders. If someone exploits a vulnerability and gets access to a shell, he could potentially gain root privileges on that box. It takes only one insecure account to compromise the machine. Moreover, physical intruders would be able to login to your account quite easily.

I have looked at the Ubuntu security policies, this is the actual policy for Sudo/root passwords:
<https://help.ubuntu.com/community/RootSudo>

There is, in fact, a procedure that disables the password prompt for sudo (it's described in that page under "Remove Password Prompt For sudo"), but it's officially unsupported.

Nevertheless, I agree with you, in a certain kind of way: there is a discrepancy in the way password are handled, so either 1) the check is done and the password prompt for sudo is disabled every time an empty password is chosen (maybe editing the configuration files for PAM or sudo may fix the issue once and for all), or 2) empty passwords are disallowed altogether (this choice, from a security point of view, is much better; on the contrary, it may be annoying, for example, for users who want to login automatically at boot time or who do not need a password for technical reasons - the system "database" users for PostgreSQL and MySQL are a good example).

Personally, I'd opt for the check being done, although there should be a warning against using empty passwords.

I'm asking in the IRC channels for further advice.

Alessandro Menti (elgaton) wrote :

I have managed to reproduce the bug on a freshly installed Ubuntu 11.10 box. I am altering the bug description to include the steps to reproduce the error.

Heiner Geisenberg (typischtheo) wrote :

Thanks for looking into this!

Alessandro Menti (elgaton) wrote :

Assigning the bug to the "sudo" package as that seems the most targeted.

description: updated
affects: ubuntu → sudo (Ubuntu)
summary: - No root access after setting password to 'None'
+ No administrative actions possible (password refused) after enabling
+ passwordless login
Dave Gilbert (ubuntu-treblig) wrote :

High as suggested by Elgaton; bad to get into a state where the user finds it hard to get out of and can't do admin.

Changed in sudo (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
description: updated
tags: added: testcase
tags: added: oneiric
Brian Murray (brian-murray) wrote :

I think the particular issue here is that the tool, User Accounts, is removing the user's password when you choose "Log in without a password". User Accounts is provided by the package accountsservice so I am changing the package affected to that.

affects: sudo (Ubuntu) → accountsservice (Ubuntu)
affects: accountsservice (Ubuntu) → gnome-control-center (Ubuntu)

I tried the work around and received the following

when I had put in the password twice I got
password: authentication token manipulation error
passwd; password unchanged

Regards Mike
On 8 November 2011 07:52, Brian Murray <email address hidden> wrote:
> ** Package changed: accountsservice (Ubuntu) => gnome-control-center
> (Ubuntu)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/882255
>
> Title:
>  No administrative actions possible (password refused) after enabling
>  passwordless login
>
> Status in “gnome-control-center” package in Ubuntu:
>  Triaged
>
> Bug description:
>  If I choose not to have a password for my operating account, every
>  operation fails if it needs root access. Reproducible even on a newly
>  set up machine. See: http://ubuntuforums.org/showthread.php?t=1862543
>
>  Release: 11.10
>
>  Steps to reproduce:
>  1. Install Ubuntu 11.10 as normal. During installation, when you are asked to choose a password, enter one, since the installation can not continue if you do not do so.
>  2. Boot the newly installed system and log in as usual.
>  3. Choose "System Settings" from the launcher on the left and open "User Accounts".
>  4. In the User Accounts window, click on Unlock at the top right of the dialog. Enter your user password when prompted.
>  5. Click on the four dots next to the "Password" label to change your password.
>  6. Select "Log in without a password" from the dropdown box. Close the window.
>  7. Try to perform an action requiring administrative privileges. For example, try running "sudo apt-get update" from a terminal.
>
>  Expected behavior:
>  sudo should require the user's password and accept it, or proceed without requiring any password altogether.
>
>  Actual behavior:
>  sudo requires the user's password and does not accept it (since it is set to an empty string in /etc/shadow).
>
>  Further notes:
>  After disabling the password request at login, the /etc/shadow file related to the test user account I created looked like this:
>  test::15283:0:99999:7:::
>  This shows that the password hash is made completely empty; that conflicts with the policies listed in /etc/sudoers, which require a password to be given in order to
>
>  Workaround:
>  -If you can not perform administrative actions but can still login without a password, open a terminal and type "passwd". This command should prompt you for a new password and change it without any problems.
>  -If you can not login, you can reset your password by booting into recovery mode and changing it there. Follow the instructions at <http://psychocats.net/ubuntu/resetpassword>.
>
>  You may also choose to use a password for your account and to enable
>  autologin at the same time. This choice will enable you to benefit the
>  advantage of not entering a password at boot time with the security of
>  Ubuntu requiring your password when attempting to perform privileged
>  actions.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/882255/+subscriptions
>

--
Kind Regards

Mike Barber

Changed in gnome-control-center (Ubuntu):
assignee: nobody → Rodrigo Moya (rodrigo-moya)
ceg (ceg) wrote :

Istn't the feature part of the “gnome-system-tools” package?

Changed in gnome-control-center (Ubuntu):
assignee: Rodrigo Moya (rodrigo-moya) → nobody

The bug has been disussed at UbuntuForums Ubuntu+1 sub-forum by Precise testers at http://ubuntuforums.org/showthread.php?t=1933237 and confirmed. It's a serious one: Unadvised users may easily get locked out of their systems.

In case users get locked out of their system, the description of the workaround to regain access is also presented in that thread.

@MIkeBarber: Follow the instructions at the thread I posted above. You are trying to set a password for your user via Root Shell, and that is correct, but only as long as the system is remounted read-write. The error message you refer point out that the '/' mount point is in read-only mode.

Regards,
Effenberg

tags: added: precise
Dale Beaudoin (twocamels) wrote :

Definitely a potentially serious lock-out bug.
Nice work Al.

Shahar Or (mightyiam) on 2012-06-02
description: updated
description: updated
Shaju (ilamkaat) wrote :

I am affected with Password problem . I have been using a strong passwd.
a few days back it began.
 While log in i have to enter password for a second time. at first time the log in window refuse permission. But when entering the password for a second time , allows log in.
I am using a laptop and my key board marking are not visible , is using a key board through usb.
Today I was totally refused login while booting. So I rebooted system and change my password through recovery , and when came back for login to desktop, the new password which was by -heart to me was rejected. So i have to went back repeat pwd change process. Then used the new pwd to log in . the next thing i did was to log into users and group session and taken option for to log in with out a password. when rebooted and attempted login , the log in window appeared and refused entry without password. When i gave my password , allowed log in.
A window option for kerying also is asking similar repeated incident for password even the correct password is entered. After a few repetition with the same pass word , it allows acceptance of the same password. something wicked is playing.

Shaju (ilamkaat) wrote :

i am using 10. 10 .
 when an upgrade listed through update-manager i tried for it but cancelled twice for want of time for downloading.
But when approached for upgrade again , the answer was no upgrade possible.

Run command for listing upgrade through update-manager failed for unknown reason
 repeatedly.
So i un- installed update-manager, and when tried for installing back , the answer was 'update-manager could not be installed. Update through synaptic also was blocked. No update or installation of any thing new was refused. On an attempt to recover update-manager i installed kdb environment , could installed back up-date manger there. Subsequently the ignome version appeared back . now the upgrade option is listed back through Update manager.

ceg (ceg) on 2012-11-17
description: updated
ceg (ceg) on 2012-11-17
description: updated

As far as I know, the gnome-system-tools are not affected as the whole nopasswdlogin thing was introduced precisely in this package. The bug is in the new gnome-control-center 3 users panel, which uses accountsservice.

Changed in gnome-system-tools (Ubuntu):
status: New → Invalid
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in accountsservice (Ubuntu):
status: New → Confirmed
Changed in lightdm (Ubuntu):
status: New → Confirmed
tags: added: raring saucy
Changed in accountsservice (Ubuntu):
importance: Undecided → High
Changed in lightdm (Ubuntu):
importance: Undecided → High
Changed in gnome-system-tools (Ubuntu):
importance: Undecided → High
Changed in accountsservice (Ubuntu):
status: Confirmed → Triaged
Changed in lightdm (Ubuntu):
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions