Hm, while writing the SRU template, I'm back wondering if src:shadow is the best place for the fix. My main concern now is that by making the change to src:shadow, ALL ubuntu users will get this update, even those not using sssd or not affected by the bug. In contrast, by silencing the error message via an update to src:sssd, less ubuntu users would be subject to this SRU, making the blast radius much smaller. I will converse with my peers, and might change my mind.
** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. + When using cloud-init to add a local user with a specific password/hash + to the system at first boot, and sssd-tools also happens to be installed + but sssd itself is not configured yet, a sequence of events leads to + that user having no password set: - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + - the user is created with the specified password hash just fine + - cloud-init calls[1] "passwd -u" on the user + - that passwd call ends up also calling "sss_cache -UG"[2], to reset the sssd cache, since the src:shadow package (where bin:passwd comes from) is built with sssd support[3] by default + - calling "sss_cache -UG" on a system with no valid sssd configuration yet prints an error message to stderr about a missing config.ldb, but exits with 0. This is since commits [4][5]. Those commits also changed sss_cache so that it no longer generates the config.ldb database, hence why it now always complains. + - cloud-init checks exit status, and stderr, of the "passwd -u" call. It sees that stderr has content[6], and assumes a failure, proceeding to calling "passwd -d" on that account. This is what deletes the password hash from the user. + + For this SRU, I opted to silence the error from the caller's side + (src:shadow) if there is no config.ldb database present. That call is a + best effort attempt to be helpful and clear the sssd cache, and the + result of the call is being ignored anyway. + + What's not so pretty about this patch is the hardcoded path to the + config.ldb database, but we are contained in ubuntu, the fix is for + ubuntu, and that's the place, so it shouldn't be a problem for the SRU, + but is likely not acceptable for upstream. + + Fedora (which is the sssd upstream) opted to entirely disable[7] sssd + support in src:shadow. That is an option to consider for devel releases + of ubuntu, but not an SRU. + + Another option could be to silence the error from within sss_cache, but + it's reasonable to expect a user would like to know about the missing + configuration, even though the exit status is zero. + + + 1. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1059 + 2. https://git.launchpad.net/ubuntu/+source/shadow/tree/src/passwd.c?h=applied/ubuntu/devel#n1175 + 3. https://git.launchpad.net/ubuntu/+source/shadow/tree/configure.ac?h=applied/ubuntu/devel#n202 + 4. https://github.com/SSSD/sssd/commit/a008accecd6d0b35e8d57d738ee3d05863aa7d0f + 5. https://github.com/SSSD/sssd/commit/50b4579413c1146a2fced5ced19977e13790731c + 6. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1063 + 7. https://src.fedoraproject.org/rpms/shadow-utils/c/1820858d26f633482d3679d1c97324e25e3c1df8?branch=rawhide [ Test Plan ] - * detailed instructions how to reproduce the bug + * detailed instructions how to reproduce the bug - * Ideally this is a well written and commented autopkgtest added as part - of the upload that way it is verified mostly by automation and will - ensure it is not breaking later + * Ideally this is a well written and commented autopkgtest added as part + of the upload that way it is verified mostly by automation and will + ensure it is not breaking later - * When an autopkgtest isn't feasible the next best option is to - attach a script to the SRU bug that can be used in certain special - conditions/environments to recreate the issue + * When an autopkgtest isn't feasible the next best option is to + attach a script to the SRU bug that can be used in certain special + conditions/environments to recreate the issue - * When neither autopkgtest nor a test script is applicable please - outline the steps needed. These should allow someone who is not - familiar with the affected package to reproduce the bug and verify - that the updated package fixes the problem. + * When neither autopkgtest nor a test script is applicable please + outline the steps needed. These should allow someone who is not + familiar with the affected package to reproduce the bug and verify + that the updated package fixes the problem. - * if other testing is appropriate to perform before landing this - update, this should also be described here. + * if other testing is appropriate to perform before landing this + update, this should also be described here. [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + * Think about what the upload changes in the software. Imagine the + change is wrong or breaks something else: how would this show up? - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the event + of a regression. - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + * This must never be "None" or "Low", or entirely an argument as to why + your upload is low risk. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. [ Other Info ] - * Anything else you think is useful to include + * Anything else you think is useful to include - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. + * Make sure to explain any deviation from the norm, to save the SRU + reviewer from having to infer your reasoning, possibly incorrectly. + This should also help reduce review iterations, particularly when the + reason for the deviation is not obvious. - * Anticipate questions from users, SRU, +1 maintenance, security teams - and the Technical Board and address these questions in advance + * Anticipate questions from users, SRU, +1 maintenance, security teams + and the Technical Board and address these questions in advance [ Original Description ] Installed ubuntu-desktop in 26.04 server, and it didn't generate config.ldb file which kept deleting the password configured by cloud- init user data. ubuntu@ip-10-0-1-145:~$ sudo passwd -u ubuntu 2>&1 [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? passwd: password changed. ubuntu@ip-10-0-1-145:~$ echo "exit: $?" exit: 0 there are output even though exit code 0 which triggers passwd -d in cloud-init script ** Description changed: [ Impact ] When using cloud-init to add a local user with a specific password/hash to the system at first boot, and sssd-tools also happens to be installed but sssd itself is not configured yet, a sequence of events leads to that user having no password set: - the user is created with the specified password hash just fine - cloud-init calls[1] "passwd -u" on the user - - that passwd call ends up also calling "sss_cache -UG"[2], to reset the sssd cache, since the src:shadow package (where bin:passwd comes from) is built with sssd support[3] by default + - that passwd call ends up also calling "sss_cache -UG"[2], to reset the sssd cache, since the src:shadow package (where bin:passwd comes from) is built with sssd support[3] by default. If sss_cache is not available (bin:sssd-tools not installed), the bug does not manifest itself. - calling "sss_cache -UG" on a system with no valid sssd configuration yet prints an error message to stderr about a missing config.ldb, but exits with 0. This is since commits [4][5]. Those commits also changed sss_cache so that it no longer generates the config.ldb database, hence why it now always complains. - cloud-init checks exit status, and stderr, of the "passwd -u" call. It sees that stderr has content[6], and assumes a failure, proceeding to calling "passwd -d" on that account. This is what deletes the password hash from the user. For this SRU, I opted to silence the error from the caller's side (src:shadow) if there is no config.ldb database present. That call is a best effort attempt to be helpful and clear the sssd cache, and the result of the call is being ignored anyway. What's not so pretty about this patch is the hardcoded path to the config.ldb database, but we are contained in ubuntu, the fix is for ubuntu, and that's the place, so it shouldn't be a problem for the SRU, but is likely not acceptable for upstream. Fedora (which is the sssd upstream) opted to entirely disable[7] sssd support in src:shadow. That is an option to consider for devel releases of ubuntu, but not an SRU. Another option could be to silence the error from within sss_cache, but it's reasonable to expect a user would like to know about the missing configuration, even though the exit status is zero. - 1. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1059 2. https://git.launchpad.net/ubuntu/+source/shadow/tree/src/passwd.c?h=applied/ubuntu/devel#n1175 3. https://git.launchpad.net/ubuntu/+source/shadow/tree/configure.ac?h=applied/ubuntu/devel#n202 4. https://github.com/SSSD/sssd/commit/a008accecd6d0b35e8d57d738ee3d05863aa7d0f 5. https://github.com/SSSD/sssd/commit/50b4579413c1146a2fced5ced19977e13790731c 6. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1063 7. https://src.fedoraproject.org/rpms/shadow-utils/c/1820858d26f633482d3679d1c97324e25e3c1df8?branch=rawhide [ Test Plan ] * detailed instructions how to reproduce the bug * Ideally this is a well written and commented autopkgtest added as part of the upload that way it is verified mostly by automation and will ensure it is not breaking later * When an autopkgtest isn't feasible the next best option is to attach a script to the SRU bug that can be used in certain special conditions/environments to recreate the issue * When neither autopkgtest nor a test script is applicable please outline the steps needed. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance [ Original Description ] Installed ubuntu-desktop in 26.04 server, and it didn't generate config.ldb file which kept deleting the password configured by cloud- init user data. ubuntu@ip-10-0-1-145:~$ sudo passwd -u ubuntu 2>&1 [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? passwd: password changed. ubuntu@ip-10-0-1-145:~$ echo "exit: $?" exit: 0 there are output even though exit code 0 which triggers passwd -d in cloud-init script ** Description changed: [ Impact ] When using cloud-init to add a local user with a specific password/hash to the system at first boot, and sssd-tools also happens to be installed but sssd itself is not configured yet, a sequence of events leads to that user having no password set: - the user is created with the specified password hash just fine - cloud-init calls[1] "passwd -u" on the user - that passwd call ends up also calling "sss_cache -UG"[2], to reset the sssd cache, since the src:shadow package (where bin:passwd comes from) is built with sssd support[3] by default. If sss_cache is not available (bin:sssd-tools not installed), the bug does not manifest itself. - calling "sss_cache -UG" on a system with no valid sssd configuration yet prints an error message to stderr about a missing config.ldb, but exits with 0. This is since commits [4][5]. Those commits also changed sss_cache so that it no longer generates the config.ldb database, hence why it now always complains. - cloud-init checks exit status, and stderr, of the "passwd -u" call. It sees that stderr has content[6], and assumes a failure, proceeding to calling "passwd -d" on that account. This is what deletes the password hash from the user. For this SRU, I opted to silence the error from the caller's side (src:shadow) if there is no config.ldb database present. That call is a best effort attempt to be helpful and clear the sssd cache, and the result of the call is being ignored anyway. What's not so pretty about this patch is the hardcoded path to the config.ldb database, but we are contained in ubuntu, the fix is for ubuntu, and that's the place, so it shouldn't be a problem for the SRU, but is likely not acceptable for upstream. Fedora (which is the sssd upstream) opted to entirely disable[7] sssd support in src:shadow. That is an option to consider for devel releases of ubuntu, but not an SRU. Another option could be to silence the error from within sss_cache, but it's reasonable to expect a user would like to know about the missing configuration, even though the exit status is zero. 1. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1059 2. https://git.launchpad.net/ubuntu/+source/shadow/tree/src/passwd.c?h=applied/ubuntu/devel#n1175 3. https://git.launchpad.net/ubuntu/+source/shadow/tree/configure.ac?h=applied/ubuntu/devel#n202 4. https://github.com/SSSD/sssd/commit/a008accecd6d0b35e8d57d738ee3d05863aa7d0f 5. https://github.com/SSSD/sssd/commit/50b4579413c1146a2fced5ced19977e13790731c 6. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1063 7. https://src.fedoraproject.org/rpms/shadow-utils/c/1820858d26f633482d3679d1c97324e25e3c1df8?branch=rawhide [ Test Plan ] - * detailed instructions how to reproduce the bug + There is a script attached to this bug which will reproduce the bug. It + assumes a working lxd setup, and that "lxc launch ubuntu-daily:<ubuntu- + release-name>" produces a working container. - * Ideally this is a well written and commented autopkgtest added as part - of the upload that way it is verified mostly by automation and will - ensure it is not breaking later + The script will exercise the following aspects of this bug: + - provide the necessary cloud-init user-data to trigger the bug + - check that the user has a password set or not in the end + - check that "passwd -u" produces or not the stderr output that triggers the bug + - check that "sss_cache -UG" *always* produces the stderr output, i.e., didn't change behavior. This also validates that we will not get false results by seeing no stderr output from "passwd -u" and assume everything is fine just because of that. - * When an autopkgtest isn't feasible the next best option is to - attach a script to the SRU bug that can be used in certain special - conditions/environments to recreate the issue + To run the test, download the script to some directory and make it + executable: - * When neither autopkgtest nor a test script is applicable please - outline the steps needed. These should allow someone who is not - familiar with the affected package to reproduce the bug and verify - that the updated package fixes the problem. + wget <TBD> + chmod +x lp2153951-test.sh - * if other testing is appropriate to perform before landing this - update, this should also be described here. + Then run it targeting the ubuntu release under test. For example, for + resolute: + + ./lp2153951-test.sh --release resolute + + That should reproduce the error, i.e., the script must indicate the test + as having failed. + + To test the fixed packages, pass the "--pocket proposed" parameter. + Again with the resolute example: + + ./lp2153951-test.sh --release resolute --pocket proposed + + This time the script should indicate that all checks have passed, and + that completes the verification for this SRU. + [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance [ Original Description ] Installed ubuntu-desktop in 26.04 server, and it didn't generate config.ldb file which kept deleting the password configured by cloud- init user data. ubuntu@ip-10-0-1-145:~$ sudo passwd -u ubuntu 2>&1 [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? passwd: password changed. ubuntu@ip-10-0-1-145:~$ echo "exit: $?" exit: 0 there are output even though exit code 0 which triggers passwd -d in cloud-init script ** Description changed: [ Impact ] When using cloud-init to add a local user with a specific password/hash to the system at first boot, and sssd-tools also happens to be installed but sssd itself is not configured yet, a sequence of events leads to that user having no password set: - the user is created with the specified password hash just fine - cloud-init calls[1] "passwd -u" on the user - that passwd call ends up also calling "sss_cache -UG"[2], to reset the sssd cache, since the src:shadow package (where bin:passwd comes from) is built with sssd support[3] by default. If sss_cache is not available (bin:sssd-tools not installed), the bug does not manifest itself. - calling "sss_cache -UG" on a system with no valid sssd configuration yet prints an error message to stderr about a missing config.ldb, but exits with 0. This is since commits [4][5]. Those commits also changed sss_cache so that it no longer generates the config.ldb database, hence why it now always complains. - cloud-init checks exit status, and stderr, of the "passwd -u" call. It sees that stderr has content[6], and assumes a failure, proceeding to calling "passwd -d" on that account. This is what deletes the password hash from the user. For this SRU, I opted to silence the error from the caller's side (src:shadow) if there is no config.ldb database present. That call is a best effort attempt to be helpful and clear the sssd cache, and the result of the call is being ignored anyway. What's not so pretty about this patch is the hardcoded path to the config.ldb database, but we are contained in ubuntu, the fix is for ubuntu, and that's the place, so it shouldn't be a problem for the SRU, but is likely not acceptable for upstream. Fedora (which is the sssd upstream) opted to entirely disable[7] sssd support in src:shadow. That is an option to consider for devel releases of ubuntu, but not an SRU. Another option could be to silence the error from within sss_cache, but it's reasonable to expect a user would like to know about the missing configuration, even though the exit status is zero. 1. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1059 2. https://git.launchpad.net/ubuntu/+source/shadow/tree/src/passwd.c?h=applied/ubuntu/devel#n1175 3. https://git.launchpad.net/ubuntu/+source/shadow/tree/configure.ac?h=applied/ubuntu/devel#n202 4. https://github.com/SSSD/sssd/commit/a008accecd6d0b35e8d57d738ee3d05863aa7d0f 5. https://github.com/SSSD/sssd/commit/50b4579413c1146a2fced5ced19977e13790731c 6. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1063 7. https://src.fedoraproject.org/rpms/shadow-utils/c/1820858d26f633482d3679d1c97324e25e3c1df8?branch=rawhide [ Test Plan ] There is a script attached to this bug which will reproduce the bug. It assumes a working lxd setup, and that "lxc launch ubuntu-daily:<ubuntu- release-name>" produces a working container. The script will exercise the following aspects of this bug: - provide the necessary cloud-init user-data to trigger the bug - check that the user has a password set or not in the end - check that "passwd -u" produces or not the stderr output that triggers the bug - check that "sss_cache -UG" *always* produces the stderr output, i.e., didn't change behavior. This also validates that we will not get false results by seeing no stderr output from "passwd -u" and assume everything is fine just because of that. To run the test, download the script to some directory and make it executable: wget <TBD> chmod +x lp2153951-test.sh Then run it targeting the ubuntu release under test. For example, for resolute: ./lp2153951-test.sh --release resolute That should reproduce the error, i.e., the script must indicate the test as having failed. To test the fixed packages, pass the "--pocket proposed" parameter. Again with the resolute example: ./lp2153951-test.sh --release resolute --pocket proposed This time the script should indicate that all checks have passed, and that completes the verification for this SRU. + Here is run that shows the bug being reproduced: + + $ ./lp2153951-test.sh --release resolute + Launching resolute container lp2153951-1955635 (phase 1: repositories + packages) + Launching lp2153951-1955635 + ...........................................................status: done + Resetting cloud-init state and rebooting (phase 2: user configuration) + status: done + + === apt-cache policy passwd (package source used in this test) === + passwd: + Installed: 1:4.17.4-2ubuntu3 + Candidate: 1:4.17.4-2ubuntu3 + Version table: + *** 1:4.17.4-2ubuntu3 500 + 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages + 100 /var/lib/dpkg/status + + === Checks === + FAIL: tuser has no hashed password in /etc/shadow (got: '<empty>') + FAIL: 'passwd -u tuser' complained about the SSSD config db on stderr: + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? + PASS: 'sss_cache -UG' reported the expected SSSD config-db error on stderr + 'sss_cache -UG' stderr was: + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? + + RESULT: FAIL + Destroying container lp2153951-1955635 + + + And here is a run showing the tests passing (I used a PPA for this example, but the real SRU verification must use "--pocket proposed"): + + $ ./lp2153951-test.sh --release resolute --pocket ppa:ahasenack/shadow-sssd-cache + Launching resolute container lp2153951-1959790 (phase 1: repositories + packages) + Launching lp2153951-1959790 + ......................................................................................status: done + Resetting cloud-init state and rebooting (phase 2: user configuration) + status: done + + === apt-cache policy passwd (package source used in this test) === + passwd: + Installed: 1:4.17.4-2ubuntu3.1~ppa2 + Candidate: 1:4.17.4-2ubuntu3.1~ppa2 + Version table: + *** 1:4.17.4-2ubuntu3.1~ppa2 500 + 500 https://ppa.launchpadcontent.net/ahasenack/shadow-sssd-cache/ubuntu resolute/main amd64 Packages + 100 /var/lib/dpkg/status + 1:4.17.4-2ubuntu3 500 + 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages + + === Checks === + PASS: tuser has a hashed password in /etc/shadow (got: '$6$lp2153951$Iq7BfvEAR8qyz9eKAKs5sAGBBtyDoSRW0D2FnBJdG3Xy5.rLbSh29Hrds0VXSNzIx/1PNNmATPReqLjginX7/.') + PASS: 'passwd -u tuser' produced no SSSD config-db complaint on stderr + PASS: 'sss_cache -UG' reported the expected SSSD config-db error on stderr + 'sss_cache -UG' stderr was: + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? + + RESULT: PASS + Destroying container lp2153951-1959790 + [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance [ Original Description ] Installed ubuntu-desktop in 26.04 server, and it didn't generate config.ldb file which kept deleting the password configured by cloud- init user data. ubuntu@ip-10-0-1-145:~$ sudo passwd -u ubuntu 2>&1 [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? passwd: password changed. ubuntu@ip-10-0-1-145:~$ echo "exit: $?" exit: 0 there are output even though exit code 0 which triggers passwd -d in cloud-init script ** Description changed: [ Impact ] When using cloud-init to add a local user with a specific password/hash to the system at first boot, and sssd-tools also happens to be installed but sssd itself is not configured yet, a sequence of events leads to that user having no password set: - the user is created with the specified password hash just fine - cloud-init calls[1] "passwd -u" on the user - that passwd call ends up also calling "sss_cache -UG"[2], to reset the sssd cache, since the src:shadow package (where bin:passwd comes from) is built with sssd support[3] by default. If sss_cache is not available (bin:sssd-tools not installed), the bug does not manifest itself. - calling "sss_cache -UG" on a system with no valid sssd configuration yet prints an error message to stderr about a missing config.ldb, but exits with 0. This is since commits [4][5]. Those commits also changed sss_cache so that it no longer generates the config.ldb database, hence why it now always complains. - cloud-init checks exit status, and stderr, of the "passwd -u" call. It sees that stderr has content[6], and assumes a failure, proceeding to calling "passwd -d" on that account. This is what deletes the password hash from the user. For this SRU, I opted to silence the error from the caller's side (src:shadow) if there is no config.ldb database present. That call is a best effort attempt to be helpful and clear the sssd cache, and the result of the call is being ignored anyway. What's not so pretty about this patch is the hardcoded path to the config.ldb database, but we are contained in ubuntu, the fix is for ubuntu, and that's the place, so it shouldn't be a problem for the SRU, but is likely not acceptable for upstream. Fedora (which is the sssd upstream) opted to entirely disable[7] sssd support in src:shadow. That is an option to consider for devel releases of ubuntu, but not an SRU. Another option could be to silence the error from within sss_cache, but it's reasonable to expect a user would like to know about the missing configuration, even though the exit status is zero. + + However, it does sound reasonable to add the fix to sss_cache itself. + It's more self contained, blast radius is smaller, only users of + bin:sssd-tools would be affected. The fix would be similar to what was + done to passwd, and that would be to silence the error message if + config.ldb is not present. This also avoids the problem of the hardcoded + path, since sssd knows there that config.ldb will always be in any + particular build. + + By adding the fix to bin:passwd instead (via src:shadow), all ubuntu + users will get this download, even those not using sssd. + 1. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1059 2. https://git.launchpad.net/ubuntu/+source/shadow/tree/src/passwd.c?h=applied/ubuntu/devel#n1175 3. https://git.launchpad.net/ubuntu/+source/shadow/tree/configure.ac?h=applied/ubuntu/devel#n202 4. https://github.com/SSSD/sssd/commit/a008accecd6d0b35e8d57d738ee3d05863aa7d0f 5. https://github.com/SSSD/sssd/commit/50b4579413c1146a2fced5ced19977e13790731c 6. https://github.com/canonical/cloud-init/blob/6193b2a0d241bed305e28a7aced1bd5c8c09de9a/cloudinit/distros/__init__.py#L1063 7. https://src.fedoraproject.org/rpms/shadow-utils/c/1820858d26f633482d3679d1c97324e25e3c1df8?branch=rawhide [ Test Plan ] There is a script attached to this bug which will reproduce the bug. It assumes a working lxd setup, and that "lxc launch ubuntu-daily:<ubuntu- release-name>" produces a working container. The script will exercise the following aspects of this bug: - provide the necessary cloud-init user-data to trigger the bug - check that the user has a password set or not in the end - check that "passwd -u" produces or not the stderr output that triggers the bug - check that "sss_cache -UG" *always* produces the stderr output, i.e., didn't change behavior. This also validates that we will not get false results by seeing no stderr output from "passwd -u" and assume everything is fine just because of that. To run the test, download the script to some directory and make it executable: wget <TBD> chmod +x lp2153951-test.sh Then run it targeting the ubuntu release under test. For example, for resolute: ./lp2153951-test.sh --release resolute That should reproduce the error, i.e., the script must indicate the test as having failed. To test the fixed packages, pass the "--pocket proposed" parameter. Again with the resolute example: ./lp2153951-test.sh --release resolute --pocket proposed This time the script should indicate that all checks have passed, and that completes the verification for this SRU. Here is run that shows the bug being reproduced: - $ ./lp2153951-test.sh --release resolute + $ ./lp2153951-test.sh --release resolute Launching resolute container lp2153951-1955635 (phase 1: repositories + packages) Launching lp2153951-1955635 ...........................................................status: done Resetting cloud-init state and rebooting (phase 2: user configuration) status: done === apt-cache policy passwd (package source used in this test) === passwd: - Installed: 1:4.17.4-2ubuntu3 - Candidate: 1:4.17.4-2ubuntu3 - Version table: - *** 1:4.17.4-2ubuntu3 500 - 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages - 100 /var/lib/dpkg/status + Installed: 1:4.17.4-2ubuntu3 + Candidate: 1:4.17.4-2ubuntu3 + Version table: + *** 1:4.17.4-2ubuntu3 500 + 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages + 100 /var/lib/dpkg/status === Checks === FAIL: tuser has no hashed password in /etc/shadow (got: '<empty>') FAIL: 'passwd -u tuser' complained about the SSSD config db on stderr: - [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured - Can't find configuration db, was SSSD configured and run? - [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured - Can't find configuration db, was SSSD configured and run? + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? PASS: 'sss_cache -UG' reported the expected SSSD config-db error on stderr - 'sss_cache -UG' stderr was: - [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured - Can't find configuration db, was SSSD configured and run? + 'sss_cache -UG' stderr was: + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? RESULT: FAIL Destroying container lp2153951-1955635 - - And here is a run showing the tests passing (I used a PPA for this example, but the real SRU verification must use "--pocket proposed"): + And here is a run showing the tests passing (I used a PPA for this + example, but the real SRU verification must use "--pocket proposed"): $ ./lp2153951-test.sh --release resolute --pocket ppa:ahasenack/shadow-sssd-cache Launching resolute container lp2153951-1959790 (phase 1: repositories + packages) Launching lp2153951-1959790 ......................................................................................status: done Resetting cloud-init state and rebooting (phase 2: user configuration) status: done === apt-cache policy passwd (package source used in this test) === passwd: - Installed: 1:4.17.4-2ubuntu3.1~ppa2 - Candidate: 1:4.17.4-2ubuntu3.1~ppa2 - Version table: - *** 1:4.17.4-2ubuntu3.1~ppa2 500 - 500 https://ppa.launchpadcontent.net/ahasenack/shadow-sssd-cache/ubuntu resolute/main amd64 Packages - 100 /var/lib/dpkg/status - 1:4.17.4-2ubuntu3 500 - 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages + Installed: 1:4.17.4-2ubuntu3.1~ppa2 + Candidate: 1:4.17.4-2ubuntu3.1~ppa2 + Version table: + *** 1:4.17.4-2ubuntu3.1~ppa2 500 + 500 https://ppa.launchpadcontent.net/ahasenack/shadow-sssd-cache/ubuntu resolute/main amd64 Packages + 100 /var/lib/dpkg/status + 1:4.17.4-2ubuntu3 500 + 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages === Checks === PASS: tuser has a hashed password in /etc/shadow (got: '$6$lp2153951$Iq7BfvEAR8qyz9eKAKs5sAGBBtyDoSRW0D2FnBJdG3Xy5.rLbSh29Hrds0VXSNzIx/1PNNmATPReqLjginX7/.') PASS: 'passwd -u tuser' produced no SSSD config-db complaint on stderr PASS: 'sss_cache -UG' reported the expected SSSD config-db error on stderr - 'sss_cache -UG' stderr was: - [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured - Can't find configuration db, was SSSD configured and run? + 'sss_cache -UG' stderr was: + [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured + Can't find configuration db, was SSSD configured and run? RESULT: PASS Destroying container lp2153951-1959790 - [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance [ Original Description ] Installed ubuntu-desktop in 26.04 server, and it didn't generate config.ldb file which kept deleting the password configured by cloud- init user data. ubuntu@ip-10-0-1-145:~$ sudo passwd -u ubuntu 2>&1 [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? [sss_cache] [sss_tool_confdb_init] (0x0010): Can't access '/var/lib/sss/db/config.ldb', probably SSSD isn't configured Can't find configuration db, was SSSD configured and run? passwd: password changed. ubuntu@ip-10-0-1-145:~$ echo "exit: $?" exit: 0 there are output even though exit code 0 which triggers passwd -d in cloud-init script -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2153951 Title: no config.ldb file under /var/lib/sss/db in 26.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2153951/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
