** Attachment added: "lp2153951-test.sh" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2153951/+attachment/6009255/+files/lp2153951-test.sh
** 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> + wget https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2153951/+attachment/6009255/+files/lp2153951-test.sh 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 -- 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
