← Back to team overview

dx-packages team mailing list archive

[Bug 882255] Re: No administrative actions possible (password refused) after enabling passwordless login

 

** 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

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to accountsservice in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/882255

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

Status in “accountsservice” package in Ubuntu:
  Triaged
Status in “gnome-control-center” package in Ubuntu:
  Triaged
Status in “gnome-system-tools” package in Ubuntu:
  Invalid
Status in “lightdm” 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

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/882255/+subscriptions