No password needed to Log in after cancel the password and then reset again

Bug #1630156 reported by Hao-Sheng Lu on 2016-10-04
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Light Display Manager
Undecided
Unassigned
OEM Priority Project
Low
Unassigned
Trusty
Low
Unassigned
Xenial
Low
Unassigned
unity-control-center (Ubuntu)
High
Iain Lane
Xenial
High
Iain Lane
Yakkety
High
Iain Lane

Bug Description

[ Description ]

If you use unity-control-center to set the current user from "Log in without a password" to having a password again, the user is not removed from the 'nopasswdlogin' UNIX group, and so can log in without a password still.

[ Test case ]

1. Open the dash, type "User Accounts", open the user accounts panel of unity-control-center.
2. Make sure the current user (which must be an admin) is selected in the list of user's on the left hand side.
3. Click "Unlock" at the top right, and enter the user's password.
4. Click the dots to the right of "Password", to open the dialog where you can change the password mode.
5. In the combo box at the top, select "Log in without a password". Save the dialog.
6. Open a terminal, and execute `grep nopasswdlogin /etc/group'. Note that the current user is present.
7. Re-open the password dialog as in step 4.
8. Select "Set a password now", and set a password. Save the dialog.
9. Open a terminal, and execute `grep nopasswdlogin /etc/group'.

At step 9, if the bug is present then the user will still be in the group. If it is fixed then the user will not.

[ Fix ]

unity-control-center's user-accounts panel contains a codepath to call `passwd' directly when changing the current user's password. There's another path when setting the password for a different user which uses AccountsService. In the former codepath, the AccountsService call required to remove the user from `nopasswdlogin' is not executed (act_user_set_password_mode (..., ACT_USER_PASSWORD_MODE_REGULAR)).

The proposed fix (in the attached MP) is to always make this call when setting a password, even in this passwd case.

[ QA ]

Run the test case above. Additionally,

 - Try to use the dialog to change passwords without unlocking it.
 - Try to change both the current and another user's password.

Make sure the nopasswdlogin membership is right at all times and the new password always gets applied (e.g. try logging out and in to check the settings).

[ Regression potential ]

The fix changes a couple of things

  - We now call act_user_set_password_mode () after running passwd.
  - We now call act_user_set_password () before act_user_set_password_mode (), which is the opposite of the previous order.

AFAIK both of these changes are fine, but we should run the QA tests above to get confidence that they didn't break password setting.

[ Original description ]

1. Go to path "System Setting --> User Accounts--> Unlock" to unlock system setting.
2. Click "Password --> Action --> Log in without password -->Change to clear Log in password. (as doing so, the user is added to group "nopasswdlogin")
3. Check that the user is in the nopasswdlogin group
4. Then do the similar action "Set a password now" as the same way to set Log in password.
5. Check that the user is *not* in the nopasswdlogin group.

The key problem is: it won't remove user from nopasswdlogin in step 4. At step 5, you are left in the group.

Related branches

Jamie Chang (jamie315) on 2016-10-05
no longer affects: oem-priority/precise
Changed in oem-priority:
importance: Undecided → High
importance: High → Critical
Ara Pulido (ara) wrote :

What version of lightdm are you using?

Is this happening in Yakkety?

Changed in lightdm (Ubuntu):
status: New → Incomplete
Hao-Sheng Lu (haosheng.lu) wrote :

lightdm version is 1.10.6
and tested with 16.04(lightdm version 1.18.2), issue still exist

Hao-Sheng Lu (haosheng.lu) wrote :

Tested with 16.10
lightdm version is 1.19.5
issue still exist

Ara Pulido (ara) on 2016-10-14
Changed in lightdm (Ubuntu):
status: Incomplete → Confirmed
Changed in oem-priority:
status: New → Confirmed
description: updated
Changed in lightdm (Ubuntu):
importance: Undecided → High
Robert Ancell (robert-ancell) wrote :

Can you check at step 5 if the user is still in the "nopasswdlogin" group? i.e. by running 'groups' as that user or checking the contents of /etc/group

Robert Ancell (robert-ancell) wrote :

Also attaching the contents of /var/log/lightdm/lightdm.log after logging in will give more information.

Hao-Sheng Lu (haosheng.lu) wrote :

Output of command "groups"
u adm cdrom sudo dip plugdev nopasswdlogin lpadmin sambashare

and lightdm.log as attached

Will Cooke (willcooke) on 2017-01-06
Changed in lightdm (Ubuntu):
assignee: nobody → Robert Ancell (robert-ancell)
Sebastien Bacher (seb128) wrote :

The issue is not a lightdm one if the user is still is the nopasswdlogin group, can't reproduce it on a xenial installation though. When you set the new password the change stick to the UI, it reflects after validating that a password has been set? Doing those steps on a test install the user is removed from the group when the new password is set...

Robert Ancell (robert-ancell) wrote :

Sounds like a duplicate of bug 1499675.

tags: added: n+1
tags: added: trusty
description: updated
affects: unity-control-center → unity-control-center (Ubuntu)
description: updated
description: updated
Yuan-Chen Cheng (ycheng-twn) wrote :

I confirm it also reproducible (user added to group "nopasswdlogin" and won't be removed.) in 17.04 current image today.
(downloaded from http://cdimage.ubuntu.com/daily-live/current/)

Iain Lane (laney) wrote :

Mmm, I did manage to reproduce and I think I fixed it.

Iain Lane (laney) on 2017-02-09
description: updated
Changed in unity-control-center (Ubuntu):
assignee: nobody → Iain Lane (laney)
status: New → Triaged
importance: Undecided → High
Iain Lane (laney) on 2017-02-09
description: updated
Changed in oem-priority:
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Xenial):
status: New → Confirmed
Changed in lightdm (Ubuntu Yakkety):
status: New → Confirmed
Changed in unity-control-center (Ubuntu Xenial):
status: New → Confirmed
Changed in unity-control-center (Ubuntu Yakkety):
status: New → Confirmed
Iain Lane (laney) on 2017-02-10
Changed in unity-control-center (Ubuntu Xenial):
assignee: nobody → Iain Lane (laney)
status: Confirmed → In Progress
Changed in unity-control-center (Ubuntu Yakkety):
assignee: nobody → Iain Lane (laney)
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-control-center - 15.04.0+17.04.20170213-0ubuntu1

---------------
unity-control-center (15.04.0+17.04.20170213-0ubuntu1) zesty; urgency=medium

  [ Iain Lane ]
  * user-accounts: Reset the AccountsService password mode when setting
    the password. There's a codepath for directly setting the password
    when the user is setting their own, but this doesn't set the AS mode
    back to ACT_USER_PASSWORD_MODE_REGULAR. If you don't change this and
    you're in ACT_USER_PASSWORD_MODE_NONE, then you end up staying in
    the nopasswdlogin group. (LP: #1630156)

  [ Robert Ancell ]
  * Add AppData (LP: #1639507)

 -- <email address hidden> (<email address hidden>) Mon, 13 Feb 2017 10:04:53 +0000

Changed in unity-control-center (Ubuntu):
status: Triaged → Fix Released
Amr Ibrahim (amribrahim1987) wrote :

The Xenial changelog in the unapproved queue is missing the LP bug number.

On Tue, Feb 14, 2017 at 08:50:22AM -0000, Amr Ibrahim wrote:
> The Xenial changelog in the unapproved queue is missing the LP bug
> number.

Thanks for your dilligence.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Mathew Hodson (mathew-hodson) wrote :

Accepted unity-control-center into -proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/unity-control-center/15.04.0+16.10.20170214-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in unity-control-center (Ubuntu Xenial):
importance: Undecided → High
status: In Progress → Fix Committed
Changed in unity-control-center (Ubuntu Yakkety):
importance: Undecided → High
status: In Progress → Fix Committed
tags: added: verification-needed
no longer affects: lightdm (Ubuntu)
no longer affects: lightdm (Ubuntu Xenial)
no longer affects: lightdm (Ubuntu Yakkety)
Changed in lightdm:
status: New → Invalid
Hao-Sheng Lu (haosheng.lu) wrote :

Try to upgrade unity-control-center form proposed,
but found the package version is 15.04.0+16.04.20170214-0ubuntu1

$ sudo apt-get install unity-control-center/xenial-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '15.04.0+16.04.20170214-0ubuntu1' (Ubuntu:16.04/xenial-proposed [amd64]) for 'unity-control-center'

Yuan-Chen Cheng (ycheng-twn) wrote :

I run the test case on xenial with the new package, it works fine and the test case passed !

But as I replace step 7 to:

close the "user accounts panel" and make sure we quit all instance of unity-control-center, and launch "user accounts panel" again, and choose to Re-open the password dialog as in step 4.

Then the test failed with after re-launch user account panel in the way

1. can't ""Click "Unlock" at the top right, and enter the user's password."" because the password is clear in step 5.
2. if we just change the password without unlock first, the system request password prompt "Authentication is required to change user data". Any password won't work for it. Then I need to press 'cancel' button, then the password is set, but user still in nopasswdlogin group.

I propose we refine the bug description instead of open a new bug. Feel free to propose otherwise.

tags: added: verification-failed
Iain Lane (laney) wrote :

On Wed, Feb 22, 2017 at 03:27:00AM -0000, Yuan-Chen Cheng wrote:
> I run the test case on xenial with the new package, it works fine and
> the test case passed !
>
> But as I replace step 7 to:
>
> close the "user accounts panel" and make sure we quit all instance of
> unity-control-center, and launch "user accounts panel" again, and choose
> to Re-open the password dialog as in step 4.
>
> Then the test failed with after re-launch user account panel in the way
>
> 1. can't ""Click "Unlock" at the top right, and enter the user's password."" because the password is clear in step 5.
> 2. if we just change the password without unlock first, the system request password prompt "Authentication is required to change user data". Any password won't work for it. Then I need to press 'cancel' button, then the password is set, but user still in nopasswdlogin group.
>
> I propose we refine the bug description instead of open a new bug. Feel
> free to propose otherwise.

TBH it's up to you. If you're saying this is a partial fix but doesn't
fix the main part of the problem for you then you can either release
this SRU and do another one to fix the rest of it, or block this one. It
doesn't really matter to me.

I would appreciate it if someone could help out on figuring out what the
problem is here though. Is it something to do with deleting the password
when you go to ACT_USER_PASSWORD_MODE_NONE? If so, what's the right
thing to do? And also, what happens if you operate on a user other than
the current one?

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Will Cooke (willcooke) wrote :

My two cents: I think we should release this fix anyway as it fixes a potential security issue. I think the use case described by YC doesn't affect this fix in a way which should prevent release.

Yuan-Chen Cheng (ycheng-twn) wrote :

per #22, mark as verification-done, and open a new bug LP: #1667222.

tags: added: verification-done
removed: n+1 trusty verification-failed verification-needed
tags: added: desktop
Changed in oem-priority:
importance: Critical → High
Changed in oem-priority:
status: In Progress → Triaged
importance: High → Medium
tags: added: verification-done-xenial
removed: verification-done
Changed in oem-priority:
importance: Medium → Low

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

Chris Halse Rogers (raof) wrote :

The verified Xenial update is being held back by this being unverified on Yakkety. Could someone please verify this update on Yakkety, so we can release this update?

Sebastien Bacher (seb128) wrote :

k, I've verified unity-control-center 15.04.0+16.10.20170214-0ubuntu1 from yakkety-proposed and it resolves the issue on my vm installation, setting as verification-done-yakkety

tags: added: verification-done-trusty
tags: added: verification-done-yakkety
removed: verification-done-trusty
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-control-center - 15.04.0+16.10.20170214-0ubuntu1

---------------
unity-control-center (15.04.0+16.10.20170214-0ubuntu1) yakkety; urgency=medium

  [ Iain Lane ]
  * user-accounts: Reset the AccountsService password mode when setting
    the password. There's a codepath for directly setting the password
    when the user is setting their own, but this doesn't set the AS mode
    back to ACT_USER_PASSWORD_MODE_REGULAR. If you don't change this and
    you're in ACT_USER_PASSWORD_MODE_NONE, then you end up staying in
    the nopasswdlogin group. (LP: #1630156)

  [ Robert Ancell ]
  * Add AppData (LP: #1639507)

 -- <email address hidden> (<email address hidden>) Tue, 14 Feb 2017 09:16:44 +0000

Changed in unity-control-center (Ubuntu Yakkety):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for unity-control-center has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-control-center - 15.04.0+16.04.20170214-0ubuntu1

---------------
unity-control-center (15.04.0+16.04.20170214-0ubuntu1) xenial; urgency=medium

  [ Iain Lane ]
  * user-accounts: Reset the AccountsService password mode when setting
    the password. There's a codepath for directly setting the password
    when the user is setting their own, but this doesn't set the AS mode
    back to ACT_USER_PASSWORD_MODE_REGULAR. If you don't change this and
    you're in ACT_USER_PASSWORD_MODE_NONE, then you end up staying in
    the nopasswdlogin group. (LP: #1630156)

  [ Robert Ancell ]
  * Add AppData (LP: #1639507)

 -- <email address hidden> (<email address hidden>) Tue, 14 Feb 2017 09:17:30 +0000

Changed in unity-control-center (Ubuntu Xenial):
status: Fix Committed → Fix Released
Changed in oem-priority:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments