After a couple restarts, there are still two tests failing: autopkgtest for nginx/1.18.0-6ubuntu14.5 for s390x autopkgtest for postgresql-14/14.15-0ubuntu0.22.04.1 for amd64
Both are due to timeouts in test infra and not related to the change here: ``` 4656s DEBUG (session:936) GET call to compute for https://nova.ps6.canonical.com:8774/v2.1/flavors?is_public=None used request id req-cdf73aee-d2b4-41e9-a21b-f53a455aa567 4656s DEBUG (session:517) REQ: curl -g -i -X GET https://nova.ps6.canonical.com:8774/v2.1/flavors/e0416e72-df6b-44d4-b3de-db9ab74cc7b3 -H "Accept: application/json" -H "OpenStack-API-Version: compute 2.87" -H "User-Agent: python-novaclient" -H "X-Auth-Token: {SHA256}11f8a82c9cca638c2af38011c0388ddcb6a0ec5a10aa3138a60f8c4efd6f502a" -H "X-OpenStack-Nova-API-Version: 2.87" 4656s DEBUG (connectionpool:429) https://nova.ps6.canonical.com:8774 "GET /v2.1/flavors/e0416e72-df6b-44d4-b3de-db9ab74cc7b3 HTTP/1.1" 200 594 4656s DEBUG (session:548) RESP: [200] Connection: Keep-Alive Content-Length: 594 Content-Type: application/json Date: Mon, 13 Jan 2025 12:14:04 GMT Keep-Alive: timeout=75, max=996nova [W] Timed out waiting for 0c1c3d1f-dc7c-48a5-a64f-aeb42f13c24f to get deleted. 4656s Unexpected error: 4656s Traceback (most recent call last): 4656s File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 833, in mainloop 4656s command() 4656s File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 762, in command 4656s r = f(c, ce) 4656s File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 395, in cmd_revert 4656s caller.hook_revert() 4656s File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-ssh", line 433, in hook_revert 4656s host_setup('revert') 4656s File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-ssh", line 252, in host_setup 4656s execute_setup_script(command) 4656s File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-ssh", line 209, in execute_setup_script 4656s sys.stderr.write(err) 4656s BlockingIOError: [Errno 11] write could not complete without blocking 4656s autopkgtest [13:19:52]: ERROR: testbed failure: unexpected eof from the testbed ``` I believe this can be ignored. Is it OK to move to jammy-updates? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1957024 Title: pam-mkhomedir does not honor private home directories Status in pam package in Ubuntu: Fix Released Status in pam source package in Focal: In Progress Status in pam source package in Jammy: Fix Committed Status in pam source package in Noble: Fix Released Status in pam source package in Oracular: Fix Released Status in pam source package in Plucky: Fix Released Bug description: [Impact] A common situation is to have a central set of users (e.g. in LDAP) and use pam_mkhomedir.so to create the home directory when the user first logs in. These changes do not cover this situation. The default configuration of pam_mkhomedir.so will result in a home directory created with 0755 permissions. To make pam_mkhomedir.so create a home directory by default with permissions consistent with the other tools then a umask argument can be added to the pam_mkhomedir.so module in the file /usr/share/pam- configs/mkhomedir. I believe this would have to be done before enabling the module. The file is part of the libpam-modules package. [Test plan] 1. Test with current defaults and confirm the permission is 0755 for home directory. # enable pam_mkhomedir.so configuration pam-auth-update --enable mkhomedir # create a user with adduser that creates the home directory adduser --disabled-password --gecos adduser homemadebyadduser # create a user with useradd that creates the home directory useradd --create-home homemadebyuseradd # create a user with useradd that does *not* create the home directory so that pam_mkhomedir.so can create it useradd --no-create-home homemadebymkhomedir # trigger pam_mkhomedir.so to create the home directory su - homemadebymkhomedir -c exit # verify the permissions are 0755 for the one created by pam and 0750 for the one by adduser' root@ubuntu:~# ls -al /home 2. Install the package with the fix # enable mkhomedir again pam-auth-update --enable mkhomedir # create a user with useradd that does *not* create the home directory so that pam_mkhomedir.so can create it useradd --no-create-home homemadebymkhomedirpatch # trigger pam_mkhomedir.so to create the home directory su - homemadebymkhomedirpatch -c exit # verify that the home dir created by pam has 0750 as well [ Where problems could occur ] This could result in inconsistent permissions between existing home directories created by pam (before the fix) and the ones created with this fix. While there's no reason to believe it could result in any actual issues, this can be mitigated by changing the existing home directories to have 0750 for consistency. Anyone in the 'others' group will lose access to the home directories of the rest of the users whose $HOME was created by pam. That behaviour should be treated as unexpected as that's how $HOME adduser will behave. In general, one's not expected to have access to $HOME of others. In the absolute pathological cases, where it's desired to give to $HOME to everyone, the permissions can be adjusted manually and the umask can be changed in the conf file on those systems. But this should be treated as 'workaround' and non-standard behaviour. [other info] This has been at https://discourse.ubuntu.com/t/private-home- directories-for-ubuntu-21-04-onwards/19533/13: And agreed that (1) having $HOME consistent across tools is the right behaviour and (2) 0750 is the desired permission for $HOME. This has been merged into Plucky already: https://git.launchpad.net/ubuntu/+source/pam/commit/?id=c576b5c19abb383ce53dfc10a986d7cf164eaeaf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1957024/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
