[Group.of.nepali.translators] [Bug 1630156] Re: No password needed to Log in after cancel the password and then reset again
** Changed in: oem-priority/xenial Status: Confirmed => Fix Released ** Changed in: oem-priority/trusty Status: Confirmed => Fix Committed ** Changed in: oem-priority Status: Triaged => Fix Released ** Changed in: oem-priority/trusty Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1630156 Title: No password needed to Log in after cancel the password and then reset again Status in Light Display Manager: Invalid Status in OEM Priority Project: Fix Released Status in OEM Priority Project trusty series: Fix Released Status in OEM Priority Project xenial series: Fix Released Status in unity-control-center package in Ubuntu: Fix Released Status in unity-control-center source package in Xenial: Fix Released Status in unity-control-center source package in Yakkety: Fix Released 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. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1630156/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1630156] Re: No password needed to Log in after cancel the password and then reset again
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) -- i...@orangesquash.org.uk (i...@orangesquash.org.uk) Tue, 14 Feb 2017 09:17:30 + ** Changed in: unity-control-center (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1630156 Title: No password needed to Log in after cancel the password and then reset again Status in Light Display Manager: Invalid Status in OEM Priority Project: Triaged Status in OEM Priority Project trusty series: Confirmed Status in OEM Priority Project xenial series: Confirmed Status in unity-control-center package in Ubuntu: Fix Released Status in unity-control-center source package in Xenial: Fix Released Status in unity-control-center source package in Yakkety: Fix Released 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. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1630156/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help :
[Group.of.nepali.translators] [Bug 1630156] Re: No password needed to Log in after cancel the password and then reset again
** Changed in: lightdm Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1630156 Title: No password needed to Log in after cancel the password and then reset again Status in Light Display Manager: Invalid Status in OEM Priority Project: In Progress Status in OEM Priority Project trusty series: Confirmed Status in OEM Priority Project xenial series: Confirmed Status in unity-control-center package in Ubuntu: Fix Released Status in unity-control-center source package in Xenial: Fix Committed Status in unity-control-center source package in Yakkety: Fix Committed 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. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1630156/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1630156] Re: No password needed to Log in after cancel the password and then reset again
** No longer affects: lightdm (Ubuntu) ** No longer affects: lightdm (Ubuntu Xenial) ** No longer affects: lightdm (Ubuntu Yakkety) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1630156 Title: No password needed to Log in after cancel the password and then reset again Status in Light Display Manager: New Status in OEM Priority Project: In Progress Status in OEM Priority Project trusty series: Confirmed Status in OEM Priority Project xenial series: Confirmed Status in unity-control-center package in Ubuntu: Fix Released Status in unity-control-center source package in Xenial: Fix Committed Status in unity-control-center source package in Yakkety: Fix Committed 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. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1630156/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1630156] Re: No password needed to Log in after cancel the password and then reset again
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) -- i...@orangesquash.org.uk (i...@orangesquash.org.uk) Mon, 13 Feb 2017 10:04:53 + ** Changed in: unity-control-center (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1630156 Title: No password needed to Log in after cancel the password and then reset again Status in Light Display Manager: New Status in OEM Priority Project: In Progress Status in OEM Priority Project trusty series: Confirmed Status in OEM Priority Project xenial series: Confirmed Status in lightdm package in Ubuntu: Confirmed Status in unity-control-center package in Ubuntu: Fix Released Status in lightdm source package in Xenial: Confirmed Status in unity-control-center source package in Xenial: In Progress Status in lightdm source package in Yakkety: Confirmed Status in unity-control-center source package in Yakkety: In Progress 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. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1630156/+subscriptions ___ Mailing list:
