[Touch-packages] [Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child
** Changed in: sssd (Ubuntu Focal) Assignee: Sergio Durigan Junior (sergiodj) => Marco Trevisan (Treviño) (3v1n0) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child Status in ca-certificates package in Ubuntu: New Status in sssd package in Ubuntu: Fix Released Status in ca-certificates source package in Focal: New Status in sssd source package in Focal: New Bug description: [ Impact ] SSSD supports in 20.04 two security backends: NSS and OpenSSL (speaking in past tense as upstream dropped NSS support completely). Those two backends are used for various generic crypto features (so they are interchangeable), but also for the management of the PKCS#11 modules for smart cards. In this case, the main problem is that by using NSS it also relies on the presence of a "system NSS" database [1] that is something present in Fedora and RHEL, but not in ubuntu or generic Linux distributions. In order to make SSSD to find a smart card module, we would then need to create a such database that mentions a p11kit proxy that will eventually load the p11-kit module and then add the card CA certificate to the same DB (see more details in [2]). And even in such case... It will not work at login phase. This is making support for Smart-card based authentication in 20.04 quite complicated, and hard to implement in professional environments (see bug #1865226). As per this, recompiling SSSD's p11_child to use OpenSSL (as it already happens starting from 20.10) would be enough to make the this tool (the one in charge for smartcard authentications and certificate matching) to be able to get the smartcard devices from p11-kit allowed modules and to check their certificate using CA certificates in the ubuntu system ca certificate files (or other configured file). One more mayor reason to do this, is also that if we fix 20.04 now to use the "proper" method, people who will configure smartcard access there via SSSD (not easily possible right now) won't be affected by future migrations. [ Proposed Implementations ] 1) Use p11-kit and openssl for p11_child, by changing the build/test system (preferred) https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child 2) Build both versions and package things accordingly (hackish) https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1 3) Recompile SSSD completely to use libcrypto as backend The option 3) has been finally choosen, but we also require migration scripts on upgrade. [ Test case ] With a smartcard reader available (and with a card in its slot) as reported by: $ p11-kit list-modules launch: $ sudo /usr/libexec/sssd/p11_child --pre -d 10 --debug-fd=2 \ --nssdb=/etc/ssl/certs/ca-certificates.crt The tool should find your card: (2020-11-26 21:34:22:020395): [p11_child[100729]] [do_card] (0x4000): Module List: (2020-11-26 21:34:22:020481): [p11_child[100729]] [do_card] (0x4000): common name: [p11-kit-trust]. (2020-11-26 21:34:22:020497): [p11_child[100729]] [do_card] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so]. (2020-11-26 21:34:22:020569): [p11_child[100729]] [do_card] (0x4000): Description [/etc/ssl/certs/ca-certificates.crt PKCS#11 Kit ] Manufacturer [PKCS#11 Kit ] flags [1] removable [false] token present [true]. (2020-11-26 21:34:22:020611): [p11_child[100729]] [do_card] (0x4000): common name: [opensc-pkcs11]. (2020-11-26 21:34:22:020646): [p11_child[100729]] [do_card] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so]. (2020-11-26 21:34:22:025443): [p11_child[100729]] [do_card] (0x4000): Description [VMware Virtual USB CCID 00 00 VMware ] Manufacturer [VMware ] flags [7] removable [true] token present [true]. (2020-11-26 21:34:22:025725): [p11_child[100729]] [do_card] (0x4000): Found [MARCO TREVISAN (PIN CNS0)] in slot [VMware Virtual USB CCID 00 00][0] of module [1][/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so]. Then: 1) If you previously configured SSSD match rules and/or CA certificates: - You should still get your certificate public key printed as output - Configured login with smartcard should continue working 2) If SSSD was not configured to do smartcard authentication: - p11_child may fail if the card certificate was not previously added to the trusted DB, but this is outside of this test case. - What it matters is that the card is found. [ Regression potential ] While the change may involve qui
[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
FWIW, the fix has just been pushed upstream:
https://sourceware.org/git/?p=binutils-
gdb.git;a=commit;h=2bf3b79d05bf85e41cbdcb020bd1cc424f59dd9a
If no one else beats me to it, I can try to backport it this weekend.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1818918
Title:
gdb doesn't search in debug-file-directory for .gnu_debugaltlink
Status in Apport:
Fix Released
Status in apport package in Ubuntu:
New
Status in gdb package in Ubuntu:
Confirmed
Bug description:
As far as I can tell gdb version 8.2.90 isn't searching the debug-
file-directory, which I set, for the '.gnu_debugaltlink' which is in
the debug symbols. Here's the error I'm seeing:
Type "apropos word" to search for commands related to "word".
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
could not find '.gnu_debugaltlink' file for
/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
(No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)
Here's part of an strace of what's going on behind the scenes:
lstat("/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
{st_mode=S_IFREG|0644, st_size=839744, ...}) = 0
openat(AT_FDCWD,
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
This is the only time "/usr/lib/debug" is searched, generally
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox/usr/lib/debug/" is used. I'll attach the full strace though.
For completeness here's the gdb command I'm using:
Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
/report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
--ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
--ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
-linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox//usr/bin/gnome-calculator"' --ex 'core-file
/tmp/apport_core_1b6dn6np'
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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
[Touch-packages] [Bug 1906333] [NEW] Missing dep8 tests
Public bug reported: rsyslog is missing dep8 tests, which would be really good to have given the importance of this package and the amount of delta we're currently carrying. ** Affects: rsyslog (Ubuntu) Importance: Wishlist Status: New ** Tags: needs-dep8 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1906333 Title: Missing dep8 tests Status in rsyslog package in Ubuntu: New Bug description: rsyslog is missing dep8 tests, which would be really good to have given the importance of this package and the amount of delta we're currently carrying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1906333/+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
[Touch-packages] [Bug 1905510] Re: utils-linux 2.36.1 breaks user mounts (cifs)
** Changed in: util-linux (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1905510 Title: utils-linux 2.36.1 breaks user mounts (cifs) Status in Util-Linux-ng: Fix Released Status in util-linux package in Ubuntu: Fix Committed Status in util-linux package in Debian: Unknown Bug description: I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while running the autopkgtests for the package I noticed that two tests are failing. These tests attempt to invoke mount.cifs in order to mount a user mount point. I investigated and found this on dmesg: [ 53.586709] CIFS: Attempting to mount //localhost/myshare1760 [ 53.586735] CIFS: Unknown mount option "symfollow" After some more investigation, I noticed that there are both a Debian and an upstream bug reported about this failure, and that upstream has fixed it in util-linux 2.36.2. I would be nice to have this version in hirsute so that cifs user mounts can work again. To manage notifications about this bug go to: https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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
[Touch-packages] [Bug 1905510] Re: utils-linux 2.36.1 breaks user mounts (cifs)
** Changed in: util-linux (Ubuntu) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1905510 Title: utils-linux 2.36.1 breaks user mounts (cifs) Status in Util-Linux-ng: Fix Released Status in util-linux package in Ubuntu: New Status in util-linux package in Debian: Unknown Bug description: I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while running the autopkgtests for the package I noticed that two tests are failing. These tests attempt to invoke mount.cifs in order to mount a user mount point. I investigated and found this on dmesg: [ 53.586709] CIFS: Attempting to mount //localhost/myshare1760 [ 53.586735] CIFS: Unknown mount option "symfollow" After some more investigation, I noticed that there are both a Debian and an upstream bug reported about this failure, and that upstream has fixed it in util-linux 2.36.2. I would be nice to have this version in hirsute so that cifs user mounts can work again. To manage notifications about this bug go to: https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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
[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections
Thanks for the comment, Marcin. Yes, you're right, the correct file to
edit was ssh@.service indeed. That was a thinko on my part.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1905285
Title:
socket-activated sshd breaks on concurrent connections
Status in openssh package in Ubuntu:
Triaged
Bug description:
This is mostly the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=934663.
With the default configuration of openssh-server and systemd, sshd
will complain and crash when multiple connections are made and
terminated in a quick succession, e.g. with `ssh-keyscan`. It results
in the following errors in /var/log/auth.log:
```
Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port
41460: no matching host key type found. Their offer:
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312
[preauth]
Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
```
as well as e.g. missing responses in ssh-keyscan:
```
$ ssh-keyscan -vvv {host}
debug2: fd 3 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 2
debug2: fd 4 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 4
debug2: fd 5 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 8
debug2: fd 6 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 32
debug2: fd 7 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 64
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
# {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: MACs ctos:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,z...@openssh.com
debug2: compression stoc: none,z...@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms:
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: MACs ctos:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,z...@openssh.com
debug2: compression stoc: none,z...@openssh.com
debug2:
[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections
Thanks for the report.
I was able to reproduce this bug. Basically:
$ systemctl start ssh.socket
$ ssh-keyscan localhost
Interesting enough, I wasn't able to solve the problem by setting
RuntimeDirectoryPreserve=yes. I edited sshd.service and added the
directive there, but I still see the fatal errors on /var/log/auth.log.
Maybe I'm missing something, but I don't have the time right now to dive
deep into this.
Marcin, as Seth said above, the right way to edit a systemd unit file is
to invoke "systemctl edit", which will make sure that the new .service
file is installed in a way that won't get ovewritten when you upgrade
your package/system. You might want to use the "--full" option when
invoking the command, which will already pre-fill the new file with the
contents of the original .service.
I'm marking this bug as Triaged and setting the priority to Medium.
Hopefully someone will be able to work on it soon.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1905285
Title:
socket-activated sshd breaks on concurrent connections
Status in openssh package in Ubuntu:
Triaged
Bug description:
This is mostly the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=934663.
With the default configuration of openssh-server and systemd, sshd
will complain and crash when multiple connections are made and
terminated in a quick succession, e.g. with `ssh-keyscan`. It results
in the following errors in /var/log/auth.log:
```
Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port
41460: no matching host key type found. Their offer:
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312
[preauth]
Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
```
as well as e.g. missing responses in ssh-keyscan:
```
$ ssh-keyscan -vvv {host}
debug2: fd 3 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 2
debug2: fd 4 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 4
debug2: fd 5 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 8
debug2: fd 6 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 32
debug2: fd 7 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 64
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
# {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: MACs ctos:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,z...@openssh.com
debug2: compression stoc: none,z...@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms:
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos:
[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections
** Changed in: openssh (Ubuntu)
Status: New => Triaged
** Changed in: openssh (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1905285
Title:
socket-activated sshd breaks on concurrent connections
Status in openssh package in Ubuntu:
Triaged
Bug description:
This is mostly the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=934663.
With the default configuration of openssh-server and systemd, sshd
will complain and crash when multiple connections are made and
terminated in a quick succession, e.g. with `ssh-keyscan`. It results
in the following errors in /var/log/auth.log:
```
Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port
41460: no matching host key type found. Their offer:
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312
[preauth]
Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
```
as well as e.g. missing responses in ssh-keyscan:
```
$ ssh-keyscan -vvv {host}
debug2: fd 3 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 2
debug2: fd 4 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 4
debug2: fd 5 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 8
debug2: fd 6 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 32
debug2: fd 7 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 64
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
# {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: MACs ctos:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,z...@openssh.com
debug2: compression stoc: none,z...@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms:
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: MACs ctos:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,z...@openssh.com
debug2: compression stoc: none,z...@openssh.com
debug2: languages
[Touch-packages] [Bug 1905510] Re: utils-linux 2.36.1 breaks user mounts (cifs)
Set priority to High because it will block samba from migrating, which will in turn block Python 3.9 from migrating. ** Changed in: util-linux (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1905510 Title: utils-linux 2.36.1 breaks user mounts (cifs) Status in Util-Linux-ng: Unknown Status in util-linux package in Ubuntu: New Status in util-linux package in Debian: Unknown Bug description: I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while running the autopkgtests for the package I noticed that two tests are failing. These tests attempt to invoke mount.cifs in order to mount a user mount point. I investigated and found this on dmesg: [ 53.586709] CIFS: Attempting to mount //localhost/myshare1760 [ 53.586735] CIFS: Unknown mount option "symfollow" After some more investigation, I noticed that there are both a Debian and an upstream bug reported about this failure, and that upstream has fixed it in util-linux 2.36.2. I would be nice to have this version in hirsute so that cifs user mounts can work again. To manage notifications about this bug go to: https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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
[Touch-packages] [Bug 1905510] [NEW] utils-linux 2.36.1 breaks user mounts (cifs)
Public bug reported: I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while running the autopkgtests for the package I noticed that two tests are failing. These tests attempt to invoke mount.cifs in order to mount a user mount point. I investigated and found this on dmesg: [ 53.586709] CIFS: Attempting to mount //localhost/myshare1760 [ 53.586735] CIFS: Unknown mount option "symfollow" After some more investigation, I noticed that there are both a Debian and an upstream bug reported about this failure, and that upstream has fixed it in util-linux 2.36.2. I would be nice to have this version in hirsute so that cifs user mounts can work again. ** Affects: util-linux-ng Importance: Unknown Status: Unknown ** Affects: util-linux (Ubuntu) Importance: Undecided Status: New ** Affects: util-linux (Debian) Importance: Unknown Status: Unknown ** Bug watch added: github.com/karelzak/util-linux/issues #1193 https://github.com/karelzak/util-linux/issues/1193 ** Also affects: util-linux-ng via https://github.com/karelzak/util-linux/issues/1193 Importance: Unknown Status: Unknown ** Bug watch added: Debian Bug tracker #975003 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975003 ** Also affects: util-linux (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975003 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1905510 Title: utils-linux 2.36.1 breaks user mounts (cifs) Status in Util-Linux-ng: Unknown Status in util-linux package in Ubuntu: New Status in util-linux package in Debian: Unknown Bug description: I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while running the autopkgtests for the package I noticed that two tests are failing. These tests attempt to invoke mount.cifs in order to mount a user mount point. I investigated and found this on dmesg: [ 53.586709] CIFS: Attempting to mount //localhost/myshare1760 [ 53.586735] CIFS: Unknown mount option "symfollow" After some more investigation, I noticed that there are both a Debian and an upstream bug reported about this failure, and that upstream has fixed it in util-linux 2.36.2. I would be nice to have this version in hirsute so that cifs user mounts can work again. To manage notifications about this bug go to: https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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
[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
@tdaitx asked me to take a look at this problem, and here is what I
found.
1) As he said above, the problem is that Debian/Ubuntu generate
.gnu_debugaltlink sections containing full pathnames to the DWZ alt
debug files. IMO, we should be using dwz's "--relative" option when
invoking it via dh_dwz. I will send a merge request on Salsa and
propose that we adopt this flag as a distro.
2) While we could use the workaround described in the last comment, I
think it is better if GDB is adjusted to cope with this scenario (i.e.,
having a full pathname on .gnu_debugaltlink, but having the actual DWZ
file in another directory that is also provided as the debug-file-
directory to GDB). I went ahead and submitted a patch to GDB to do just
that:
https://sourceware.org/pipermail/gdb-patches/2020-November/173276.html
I think searching for the DWZ files using the debug-file-directory
provided by the user is a sensible approach, and is also something that
other projects (namely elfutils) seem to do.
All in all, as I said in (1), I think the best long-term solution is to
adjust dh_dwz to put relative pathnames in the .gnu_debugaltlink.
Arguably, we could also create a symlink in /usr/lib/debug/.build-id/
and make it point to the corresponding file inside /usr/lib/debug/.dwz/,
but that is an orthogonal issue and would not help with this specific
bug.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1818918
Title:
gdb doesn't search in debug-file-directory for .gnu_debugaltlink
Status in Apport:
Fix Released
Status in apport package in Ubuntu:
New
Status in gdb package in Ubuntu:
Confirmed
Bug description:
As far as I can tell gdb version 8.2.90 isn't searching the debug-
file-directory, which I set, for the '.gnu_debugaltlink' which is in
the debug symbols. Here's the error I'm seeing:
Type "apropos word" to search for commands related to "word".
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
could not find '.gnu_debugaltlink' file for
/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
(No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)
Here's part of an strace of what's going on behind the scenes:
lstat("/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
{st_mode=S_IFREG|0644, st_size=839744, ...}) = 0
openat(AT_FDCWD,
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
This is the only time "/usr/lib/debug" is searched, generally
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox/usr/lib/debug/" is used. I'll attach the full strace though.
For completeness here's the gdb command I'm using:
Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
/report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
--ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
--ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
-linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox//usr/bin/gnome-calculator"' --ex 'core-file
/tmp/apport_core_1b6dn6np'
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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
[Touch-packages] [Bug 1903396] Re: libnl-route-3-200 unresolved symbols
For what it's worth, I created a Focal lxd container, followed the instructions listed in the description, but could not reproduce the issue. I was able to successfully build wireshark without problems here. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1903396 Title: libnl-route-3-200 unresolved symbols Status in libnl3 package in Ubuntu: Incomplete Bug description: $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" $ arch x86_64 Getting a link error when trying to build Wireshark from source on Ubuntu Focal. I need to build Wireshark for plugin development. Steps to reproduce: 1. Obtain source code from https://gitlab.com/wireshark/wireshark 2. Install build dependencies as per CI ./tools/debian-setup.sh --install-optional --install-test-deps -y 3. mkdir build 4. cmake .. 5. make 6. Observer error: [ 88%] Linking CXX executable run/wireshark /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libnl-route-3.so: undefined reference to `nla_get_s32' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libnl-route-3.so: undefined reference to `nl_strerror_l' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/wireshark.dir/build.make:567: run/wireshark] Error 1 make[1]: *** [CMakeFiles/Makefile2:3713: CMakeFiles/wireshark.dir/all] Error 2 make: *** [Makefile:141: all] Error 2 Those two symbols are not present in any of the other libnl libraries, static or dynamic. /usr/include/libnl3/netlink/attr.h:119:extern int32_t nla_get_s32(const struct nlattr *); $ dpkg -S /usr/include/libnl3/netlink/attr.h libnl-3-dev:amd64: /usr/include/libnl3/netlink/attr.h $ dpkg -S /usr/lib/x86_64-linux-gnu/libnl-route-3.so.200.26.0 libnl-route-3-200:amd64: /usr/lib/x86_64-linux-gnu/libnl-route-3.so.200.26.0 I can build and install libnl-3.2.25 from source and I don't get the linking issues anymore if I replace the .so files installed by the .debs, so it's possible that there is soemthing wrong with the packaging of libnl-route-3-200.deb. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1903396/+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
[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository
I'm also able to reproduce this in a hirsute lxd container today (2020-11-02). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in software-properties package in Ubuntu: Confirmed Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1902540/+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
[Touch-packages] [Bug 1896251] Re: rsync --delete-missing-args fails with "error: protocol incompatibility"
** Tags removed: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1896251 Title: rsync --delete-missing-args fails with "error: protocol incompatibility" Status in rsync package in Ubuntu: New Status in rsync source package in Xenial: Triaged Status in rsync source package in Bionic: Triaged Status in rsync source package in Focal: Triaged Bug description: Running rsync --delete-missing-args --files-from=... fails with error message like ABORTING due to invalid path from sender: dir1/dir2/dir3 rsync error: protocol incompatibility (code 2) at generator.c(1271) [generator=3.1.2] if the listed directories are trying to delete full subtree of files. According to https://bugzilla.samba.org/show_bug.cgi?id=12569 this has been fixed in version 3.2.2. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863334 Could you update the rsync package or backport the fix? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsync 3.1.2-2.1ubuntu1.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-lowlatency 5.4.55 Uname: Linux 5.4.0-47-lowlatency x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 CurrentDesktop: MATE Date: Fri Sep 18 18:27:53 2020 EcryptfsInUse: Yes InstallationDate: Installed on 2019-01-05 (621 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: rsync UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1896251/+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
[Touch-packages] [Bug 1896251] Re: rsync --delete-missing-args fails with "error: protocol incompatibility"
** Tags added: server-next ** Also affects: rsync (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: rsync (Ubuntu Xenial) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1896251 Title: rsync --delete-missing-args fails with "error: protocol incompatibility" Status in rsync package in Ubuntu: New Status in rsync source package in Xenial: Triaged Status in rsync source package in Bionic: Triaged Status in rsync source package in Focal: Triaged Bug description: Running rsync --delete-missing-args --files-from=... fails with error message like ABORTING due to invalid path from sender: dir1/dir2/dir3 rsync error: protocol incompatibility (code 2) at generator.c(1271) [generator=3.1.2] if the listed directories are trying to delete full subtree of files. According to https://bugzilla.samba.org/show_bug.cgi?id=12569 this has been fixed in version 3.2.2. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863334 Could you update the rsync package or backport the fix? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsync 3.1.2-2.1ubuntu1.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-lowlatency 5.4.55 Uname: Linux 5.4.0-47-lowlatency x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 CurrentDesktop: MATE Date: Fri Sep 18 18:27:53 2020 EcryptfsInUse: Yes InstallationDate: Installed on 2019-01-05 (621 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: rsync UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1896251/+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
[Touch-packages] [Bug 1896251] Re: rsync --delete-missing-args fails with "error: protocol incompatibility"
Thanks for the bug report, Mikko. I confirmed that this bug happens on both Bionic and Focal, but doesn't happen (or at least doesn't happen in the same way) on Groovy. Bear in mind that, when running this command using Groovy's rsync, I see: $ rsync --delete-missing-args --files-from=list a b file has vanished: "/tmp/rsync-bug/a/1/2" WARNING: parent dir is absent in the file list: 1/2 default_perms_for_dir: sys_acl_get_file(1/2, ACL_TYPE_DEFAULT): No such file or directory, falling back on umask rsync warning: some files vanished before they could be transferred (code 24) at main.c(1330) [sender=3.2.3] This is a different error from the one reported in the bug, and I think it's worth investigating whether it is another bug, or if it's just an expected error this time. FWIW, the patch needed to be backport in order to fix the initial bug on Bionic/Focal rsync is: commit af6118d98b3482cbcfc223bf2a0777bc19eccb02 Author: Wayne Davison AuthorDate: Sun Apr 26 18:02:17 2020 -0700 Commit: Wayne Davison CommitDate: Sun Apr 26 18:10:40 2020 -0700 Allow a missing parent dir when --delete-missing-args was specified. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1896251 Title: rsync --delete-missing-args fails with "error: protocol incompatibility" Status in rsync package in Ubuntu: New Status in rsync source package in Xenial: Triaged Status in rsync source package in Bionic: Triaged Status in rsync source package in Focal: Triaged Bug description: Running rsync --delete-missing-args --files-from=... fails with error message like ABORTING due to invalid path from sender: dir1/dir2/dir3 rsync error: protocol incompatibility (code 2) at generator.c(1271) [generator=3.1.2] if the listed directories are trying to delete full subtree of files. According to https://bugzilla.samba.org/show_bug.cgi?id=12569 this has been fixed in version 3.2.2. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863334 Could you update the rsync package or backport the fix? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsync 3.1.2-2.1ubuntu1.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-lowlatency 5.4.55 Uname: Linux 5.4.0-47-lowlatency x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 CurrentDesktop: MATE Date: Fri Sep 18 18:27:53 2020 EcryptfsInUse: Yes InstallationDate: Installed on 2019-01-05 (621 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: rsync UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1896251/+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
[Touch-packages] [Bug 1896251] Re: rsync --delete-missing-args fails with "error: protocol incompatibility"
** Also affects: rsync (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: rsync (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: rsync (Ubuntu Bionic) Status: New => Triaged ** Changed in: rsync (Ubuntu Focal) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1896251 Title: rsync --delete-missing-args fails with "error: protocol incompatibility" Status in rsync package in Ubuntu: New Status in rsync source package in Bionic: Triaged Status in rsync source package in Focal: Triaged Bug description: Running rsync --delete-missing-args --files-from=... fails with error message like ABORTING due to invalid path from sender: dir1/dir2/dir3 rsync error: protocol incompatibility (code 2) at generator.c(1271) [generator=3.1.2] if the listed directories are trying to delete full subtree of files. According to https://bugzilla.samba.org/show_bug.cgi?id=12569 this has been fixed in version 3.2.2. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863334 Could you update the rsync package or backport the fix? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsync 3.1.2-2.1ubuntu1.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-lowlatency 5.4.55 Uname: Linux 5.4.0-47-lowlatency x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 CurrentDesktop: MATE Date: Fri Sep 18 18:27:53 2020 EcryptfsInUse: Yes InstallationDate: Installed on 2019-01-05 (621 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: rsync UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1896251/+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
[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
Verifying that the bug is fixed. First, reproducing the bug. After firing up the container, while running "apt install squid dnsmasq -y", I see: # apt install squid dnsmasq -y ... Setting up dnsmasq (2.75-1ubuntu0.16.04.5) ... Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. invoke-rc.d: initscript dnsmasq, action "start" failed. ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled) Drop-In: /run/systemd/generator/dnsmasq.service.d └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf Active: failed (Result: timeout) since Wed 2020-09-16 15:43:01 UTC; 11ms ago Process: 1565 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=killed, signal=TERM) Process: 1554 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS) Process: 1553 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) Main PID: 1564 (code=exited, status=0/SUCCESS) Sep 16 15:41:31 squid-bug1761096 dnsmasq[1564]: started, version 2.75 cachesize 150 Sep 16 15:41:31 squid-bug1761096 dnsmasq[1564]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify Sep 16 15:41:31 squid-bug1761096 dnsmasq[1564]: DNS service limited to local subnets Sep 16 15:41:31 squid-bug1761096 dnsmasq[1564]: read /etc/hosts - 7 addresses Sep 16 15:41:31 squid-bug1761096 dnsmasq[1564]: reading /var/run/dnsmasq/resolv.conf Sep 16 15:41:31 squid-bug1761096 dnsmasq[1564]: using nameserver 10.101.133.1#53 Sep 16 15:43:01 squid-bug1761096 systemd[1]: dnsmasq.service: Start-post operation timed out. Stopping. Sep 16 15:43:01 squid-bug1761096 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server. Sep 16 15:43:01 squid-bug1761096 systemd[1]: dnsmasq.service: Unit entered failed state. Sep 16 15:43:01 squid-bug1761096 systemd[1]: dnsmasq.service: Failed with result 'timeout'. ... We also see the bug happening while restarting the dnsmasq.service: # systemctl restart dnsmasq.service Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. # systemctl status dnsmasq.service ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled) Drop-In: /run/systemd/generator/dnsmasq.service.d └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf Active: failed (Result: timeout) since Wed 2020-09-16 15:47:22 UTC; 17s ago Process: 1744 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf (code=killed, signal=TERM) Process: 1808 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=killed, signal=TERM) Process: 1799 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS) Process: 1798 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) Main PID: 1807 (code=exited, status=0/SUCCESS) Sep 16 15:45:52 squid-bug1761096 dnsmasq[1807]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify Sep 16 15:45:52 squid-bug1761096 dnsmasq[1807]: DNS service limited to local subnets Sep 16 15:45:52 squid-bug1761096 dnsmasq[1807]: no servers found in /var/run/dnsmasq/resolv.conf, will retry Sep 16 15:45:52 squid-bug1761096 dnsmasq[1807]: read /etc/hosts - 7 addresses Sep 16 15:45:52 squid-bug1761096 dnsmasq[1807]: reading /var/run/dnsmasq/resolv.conf Sep 16 15:45:52 squid-bug1761096 dnsmasq[1807]: using nameserver 10.101.133.1#53 Sep 16 15:47:22 squid-bug1761096 systemd[1]: dnsmasq.service: Start-post operation timed out. Stopping. Sep 16 15:47:22 squid-bug1761096 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server. Sep 16 15:47:22 squid-bug1761096 systemd[1]: dnsmasq.service: Unit entered failed state. Sep 16 15:47:22 squid-bug1761096 systemd[1]: dnsmasq.service: Failed with result 'timeout'. Now, installing the package containing the proposed fix, and testing that it works. After installing, restarting dnsmasq.service multiple times and verify that it always succeeds: # systemctl restart dnsmasq.service && echo $? 0 # systemctl restart dnsmasq.service && echo $? 0 # systemctl restart dnsmasq.service && echo $? 0 # systemctl restart dnsmasq.service && echo $? 0 # systemctl restart dnsmasq.service && echo $? 0 Therefore, tagging the bug as verified for Xenial. ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64
[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
I'm marking the dnsmasq bug as Invalid since this is a problem with squid/systemd. ** Changed in: squid (Ubuntu Xenial) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) ** Changed in: dnsmasq (Ubuntu Xenial) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Confirmed Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test Case] One can reproduce the issue on a Xenial container: $ lxc launch ubuntu-daily:xenial squid-bug1761096 $ lxc shell squid-bug1761096 # apt update # apt install squid dnsmasq -y It is quite possible that during "apt install" the bug will manifest, and dnsmasq will fail to start due to a timeout. The user might see a message like: Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. If the bug doesn't manifest itself during installation, the following commands in sequence should trigger it: # systemctl restart dnsmasq.service # systemctl restart dnsmasq.service [Regression Potential] This change only touches the mechanism by which squid has its configuration reloaded in case of a DNS resolver change. Because "systemctl reload --no-block" returns practically immediately, if squid's configuration file is invalid the user won't see any notifications. However, this behaviour is already present currently, because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the user has to check "journalctl -u squid.service" if she wants to verify whether there were any failures during the reload. Other than that, and because systemctl will offload the service to the SysV script as usual (in the case of squid), I don't foresee any potential regressions. [Original Description] Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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
[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
** Description changed: + [Impact] + + When using dnsmasq along with squid on Ubuntu Xenial, the user will + experience a deadlock while performing on every second execution of the + "systemctl start dnsmasq.service" command. The deadlock will be caused + by an attempt to invoke, by nss-lookup.target, a "systemctl reload + squid.service", which will itself try to start the nss-lookup.target, + which will be waiting on squid, therefore eventually leading to a + timeout. + + The underlying cause of this deadlock is related to how systemd used to + handle dependencies between multiple jobs being started in the same + transaction. + + [Test Case] + + One can reproduce the issue on a Xenial container: + + $ lxc launch ubuntu-daily:xenial squid-bug1761096 + $ lxc shell squid-bug1761096 + # apt update + # apt install squid dnsmasq -y + + It is quite possible that during "apt install" the bug will manifest, + and dnsmasq will fail to start due to a timeout. The user might see a + message like: + + Job for dnsmasq.service failed because a timeout was exceeded. See + "systemctl status dnsmasq.service" and "journalctl -xe" for details. + + If the bug doesn't manifest itself during installation, the following + commands in sequence should trigger it: + + # systemctl restart dnsmasq.service + # systemctl restart dnsmasq.service + + [Regression Potential] + + This change only touches the mechanism by which squid has its + configuration reloaded in case of a DNS resolver change. Because + "systemctl reload --no-block" returns practically immediately, if + squid's configuration file is invalid the user won't see any + notifications. However, this behaviour is already present currently, + because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the + user has to check "journalctl -u squid.service" if she wants to verify + whether there were any failures during the reload. + + Other than that, and because systemctl will offload the service to the + SysV script as usual (in the case of squid), I don't foresee any + potential regressions. + + [Original Description] + Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Confirmed Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test
Re: [Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
On Friday, September 04 2020, Christian Ehrhardt wrote: > Thanks for --no-ask-password Sergio. > > I like the suggestion of making /etc/resolvconf/update-libc.d/squid systemd > aware. >>From similar checks I know that you also want to check if it is active: > > if [ -d /run/systemd/system ]; then > ! systemctl is-active -q squid.service || systemctl reload squid.service > >/dev/null > > The above is untested, but you get my point - don't reload if it isn't > active. Thanks, Christian. Good point about checking whether the service is active; I'll incorporate that into the solution. I'll prepare an MP soon, then. Cheers, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Confirmed Status in squid source package in Xenial: Confirmed Bug description: Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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
[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
Thanks for the further investigation, Christian.
So, it doesn't seem to me that /bin/systemd-tty-ask-password-agent is
the culprit here. Actually, if you look at when it is invoked, you will
notice that it is only executed when the systemctl command is issued
from the tty, which is not our case here: the command that is hanging
("systemctl reload squid") is being invoked indirectly due to the start
of dnsmasq.service.
When we issue a "systemctl start dnsmasq", we can see /bin/systemd-tty-
ask-password-agent there, but not as a child of the "systemctl reload
squid":
root9164 0.0 0.0 26164 1040 pts/0S+ 22:23 0:00 |
\_ systemctl start dnsmasq.service
root9165 0.0 0.0 12512 2084 pts/0S+ 22:23 0:00 |
\_ /bin/bash /bin/systemd-tty-ask-password-agent --watch
This is because we invoked "systemctl start dnsmasq" from the tty. We
can easily verify that /bin/systemd-tty-ask-password-agent is not to
blame by using "systemctl --no-ask-password stop dnsmasq" and then
"systemctl --no-ask-password start dnsmasq", and verifying that the hang
still happens even though /bin/systemd-tty-ask-password-agent was not
invoked.
Anyway, continuing the investigation here, this is the output of
"systemctl list-jobs":
$ systemctl list-jobs --all
JOB UNIT TYPE STATE
2512 dnsmasq.service start running
2561 squid.service reload waiting
2560 nss-lookup.target start waiting
3 jobs listed.
Nothing really new here, except the fact that the squid reload happens
*because* of the nss-lookup.target start, and both jobs are blocked
waiting. It's interesting to notice that squid's SysV init file says
that squid "Should-Start: $named", which translated to squid trying to
start nss-lookup.target itself. I think this is a strong indicator that
we might be seeing a deadlock here.
After a bit more investigation, I found
https://github.com/systemd/systemd/issues/10464, which led me to
https://github.com/systemd/systemd/pull/13860. I tried backporting the
patch (which is very simple) and seeing if it had any impact, but
unfortunately it didn't.
I then did a quick test and hacked /usr/sbin/invoke-rc.d, specifically
around line 570, and commented out the "if" surrounding sctl_args
="--job-mode=ignore-dependencies" (in other words, I made systemctl
always use this option), and unsurprisingly the bug went away. However,
just like with the "--no-block" hack I mentioned in my previous comment,
I'm not sure this is a good solution for the problem.
As I'm running out of ideas here, I'd like to propose a possible fix for
the problem, based on what Martin Pitt wrote in one of the bug reports I
mentioned (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777113).
I'd like to suggest that we expand /etc/resolvconf/update-libc.d/squid
to take into account whether systemd is being used behind the scenes,
and invoke systemctl to reload squid while also passing "--no-block" to
it. Something like this:
if [ -d /run/systemd ]; then
systemctl --no-block reload squid
else
invoke-rc.d squid reload || true
fi
Based on local tests here, this works and has the benefit of unblocking
nss-lookup.target to also finish, which means that, by the end of the
"systemctl start dnsmasq" process, we will have both successfully
reloaded squid *and* started nss-lookup.target (as well as started
dnsmasq.service, of course).
This is not the perfect solution, of course, but I feel like we're
wasting a lot of time on this old bug already, and this solution is not
entirely bad, IMHO. We could in theory try to bisect systemd between
xenial and bionic and see if we could determine what change (or changes)
made this scenario work OK on the latter, but that's assuming that it is
systemd indeed who is causing this (I think it is, but I'm not 100% sure
yet).
Anyway, I'll wait for your answer in the morning. We can discuss this
during standup too, if you'd like.
** Bug watch added: github.com/systemd/systemd/issues #10464
https://github.com/systemd/systemd/issues/10464
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1761096
Title:
dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
Status in dnsmasq package in Ubuntu:
Fix Released
Status in squid package in Ubuntu:
Fix Released
Status in dnsmasq source package in Xenial:
Confirmed
Status in squid source package in Xenial:
Confirmed
Bug description:
Setup to reproduce:
Ubuntu Xenial amd64 net install iso from
http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-
amd64/current/images/netboot/mini.iso
Install system with mostly defaults + LVM + OpenSSH server
Note that this bug applies to both DHCP and static IP+DNS network
configurations
Once server rebooted and is available, log in and install dnsmasq + squid:
apt-get
[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
OK, I've spent some time investigating this one, so I decided to post my progress here. Unfortunately I don't have a full fix yet, but I managed to find some interesting pointers related to systemd. First of all, I confirmed what Christian and Andreas were seeing: the problem happens on every second "systemctl start dnsmasq.service"; squid takes 30 seconds to restart regardless of dnsmasq/resolvconf (this is still true nowadays, with groovy); nss-lookup.target fails to start on xenial, but does start on bionic; the issue doesn't seem to happen on bionic. As for the systemd bits I mentioned, I found these issues: - https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1417010 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777113 The good news is that they are really similar to what we're experiencing here, even though our problem doesn't seem to be cirular dependencies on systemd service files. The bad news is that the fix proposed by Martin Pitt (the last one, that ended up landing) is already available on xenial. One of the suggested fixes was to add a "--no-block" on /usr/sbin /invoke-rc.d's "systemctl reload" command. I did that, and it obviously "solves" the issue, although I'm not confident that it's the proper fix for this. Something that caught my attention is the fact that the process that is hung is actually the "systemctl reload squid", and not squid itself. I verified that "/etc/init.d/squid reload" actually exits successfully, but for some reason "systemctl reload squid" keeps waiting. With what I know so far, I feel inclined to say that this is a systemd issue, and not a dnsmasq/squid/resolvconf one (of course, we can talk about squid's 30-second restart, but that's orthogonal). I'll let you know when I have more data (or hopefully a fix). Meanwhile, I'd appreciate comments/feedback, if you have any. ** Bug watch added: Debian Bug tracker #777113 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777113 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Confirmed Status in squid source package in Xenial: Confirmed Bug description: Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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
[Touch-packages] [Bug 1888046] Re: Please merge coreutils 8.32-2 (main) from Debian unstable (main)
** Changed in: coreutils (Ubuntu) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1888046 Title: Please merge coreutils 8.32-2 (main) from Debian unstable (main) Status in coreutils package in Ubuntu: New Bug description: New coreutils features are missing in Ubuntu. Especially, "ls --time=birth" available since 8.32, and time of file creation in stat(1) on btrfs or ext4 fixed since 8.31. Please consider to incorporate these features at least into Ubuntu 20.10 (Groovy Gorilla). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1888046/+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
[Touch-packages] [Bug 1887572] [NEW] rsync blocked in -proposed due to configure.sh warning (dep8 test)
Public bug reported:
rsync 3.2.1-1ubuntu1 has been blocked in proposed due to a problem when
invoking configure.sh inside the debian/tests/upstream-tests script:
autopkgtest [18:04:18]: summary
upstream-tests FAIL stderr: configure.sh: WARNING: you should use
--build, --host, --target
Exit request sent.
The problem is that configure.sh is being executed like this:
./configure.sh "$CROSS_COMPILE"
in this scenario, $CROSS_COMPILE is an empty variable, which means that
this will evaluate to:
./configure.sh ""
which will trigger the autotools warning above. The easy solution here
is to just remove the quotes.
I'm working on this.
** Affects: rsync (Ubuntu)
Importance: Undecided
Assignee: Sergio Durigan Junior (sergiodj)
Status: In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1887572
Title:
rsync blocked in -proposed due to configure.sh warning (dep8 test)
Status in rsync package in Ubuntu:
In Progress
Bug description:
rsync 3.2.1-1ubuntu1 has been blocked in proposed due to a problem
when invoking configure.sh inside the debian/tests/upstream-tests
script:
autopkgtest [18:04:18]: summary
upstream-tests FAIL stderr: configure.sh: WARNING: you should use
--build, --host, --target
Exit request sent.
The problem is that configure.sh is being executed like this:
./configure.sh "$CROSS_COMPILE"
in this scenario, $CROSS_COMPILE is an empty variable, which means
that this will evaluate to:
./configure.sh ""
which will trigger the autotools warning above. The easy solution
here is to just remove the quotes.
I'm working on this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1887572/+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
[Touch-packages] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux
** Changed in: openldap (Ubuntu Eoan)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1557157
Title:
apparmor profile denied for saslauthd: /run/saslauthd/mux
Status in openldap package in Ubuntu:
Fix Released
Status in openldap source package in Trusty:
Won't Fix
Status in openldap source package in Xenial:
Confirmed
Status in openldap source package in Bionic:
Confirmed
Status in openldap source package in Eoan:
Confirmed
Status in openldap source package in Focal:
Confirmed
Status in openldap source package in Groovy:
Fix Released
Bug description:
[Impact]
When using openldap with sasl authentication, the slapd process will
communicate with the saslauthd daemon via a socket in
{,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
Ubuntu release from trusty onwards, because slapd's apparmor profile
doesn't contain the necessary directive to allow it to read/write
from/to the socket specified above.
The fix is simple: just add the necessary directive to allow slapd to
read/write from/to the saslauthd socket.
[Test Case]
One can reproduce the problem by doing:
$ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
$ lxc shell openldap-bugbug1557157-groovy
# apt install slapd sasl2-bin ldap-utils apparmor-utils
(As the domain name, use "example.com").
# sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
# cat > /etc/ldap/sasl2/slapd.conf << __EOF__
mech_list: PLAIN
pwcheck_method: saslauthd
__EOF__
# adduser openldap sasl
# aa-enforce /etc/apparmor.d/usr.sbin.slapd
# systemctl restart slapd.service
# systemctl restart saslauthd.service
# passwd root
(You can choose any password here. You will need to type it when
running the next command.)
# ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
-Y PLAIN
The command will fail with something like:
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: Password verification
failed
[Regression Potential]
This is an extremely simple and well contained fix, so I don't
envision any possible regressions after applying it. It is important
noticing that, since the problem affects older Ubuntu releases, the
openldap package will have to be rebuilt against possible newer
versions of libraries and other depencencies, which, albeit unlikely,
may cause issues.
[Original Description]
When using slapd with saslauthd the processes communicate via the
{,/var}/run/saslauthd/mux socket (this is the default location for the
saslauthd server from the sasl2-bin package in the
/etc/default/saslauthd config), but the apparmor profile for
usr.sbin.slapd does not allow access to this socket/file.
Syslog message:
apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd"
name="/run/saslauthd/mux" pid=1880
4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0
Please add the following line to /etc/apparmor.d/usr.sbin.slapd:
/{,var/}run/saslauthd/mux rw,
Ubuntu version: Ubuntu 14.04.4 LTS
slapd version: 2.4.31-1+nmu2ubu
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+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
Re: [Touch-packages] [Bug 1877454] Re: openssh-server hangs with AuthorizedKeysCommand
On Thursday, June 25 2020, Łukasz Zemczak wrote:
> Thank you for the verification Sergio! Could you please note down which
> package version has been used for verification and what kind of
> verification has been performed?
Hi Łukasz,
The package version I tested is 1:7.2p2-4ubuntu2.10. I performed the
steps listed in the "Test Case" section of the SRU above. Everything
worked as expected:
$ ssh root@127.0.0.1
Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 5.4.0-31-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support:https://ubuntu.com/advantage
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
$
Thanks!
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1877454
Title:
openssh-server hangs with AuthorizedKeysCommand
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Xenial:
Fix Committed
Bug description:
[Impact]
On a default Xenial install, when sshd is configured to obtain the
list of allowed keys using AuthorizedKeysCommand (or the list of
allowed certificate principals using AuthorizedPrincipalsCommand), and
if the command pointed by Authorized{Keys,Principals}Command generates
a lot of output, sshd will hang while reading this same output. In a
nutshell, the problem happens when the subprocess generates enough
data to fill the pipe's buffer; in this scenario, sshd will wait(2) on
the subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
# chmod +x authkeyscommand.sh
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply,
which won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine
whether the subprocess exited correctly; and considering that this
code is written in C without the help of features like RAII and with
the use of goto statements, we are not able to disconsider the chances
of making a mistake and forgetting to free a resource or to properly
read/write from/to pipes, for example. This is, after all, the reason
the bug happened in the first place.
Having said that, openssh contains extensive tests and the code is
well organized and relatively easy to follow. Upon close inspection,
there doesn't seem to be an evident problem with the backported fixes.
As usual when dealing with a somewhat older distribution, there is
always the possibility of encountering problems because we will be
recompiling openssh using the most recent versions of its build
dependencies.
[Original Description]
Please consider applying this change to openssh-server distributed in Xenial
(16.04).
Without it, sshd can sporadically hang when making use of the
`AuthorizedKeysCommand` option.
https://github.com/openssh/openssh-
portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1877454/+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
[Touch-packages] [Bug 1877454] Re: openssh-server hangs with AuthorizedKeysCommand
Just double checked that the fix works and tagged as verification-done-
xenial.
** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1877454
Title:
openssh-server hangs with AuthorizedKeysCommand
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Xenial:
Fix Committed
Bug description:
[Impact]
On a default Xenial install, when sshd is configured to obtain the
list of allowed keys using AuthorizedKeysCommand (or the list of
allowed certificate principals using AuthorizedPrincipalsCommand), and
if the command pointed by Authorized{Keys,Principals}Command generates
a lot of output, sshd will hang while reading this same output. In a
nutshell, the problem happens when the subprocess generates enough
data to fill the pipe's buffer; in this scenario, sshd will wait(2) on
the subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
# chmod +x authkeyscommand.sh
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply,
which won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine
whether the subprocess exited correctly; and considering that this
code is written in C without the help of features like RAII and with
the use of goto statements, we are not able to disconsider the chances
of making a mistake and forgetting to free a resource or to properly
read/write from/to pipes, for example. This is, after all, the reason
the bug happened in the first place.
Having said that, openssh contains extensive tests and the code is
well organized and relatively easy to follow. Upon close inspection,
there doesn't seem to be an evident problem with the backported fixes.
As usual when dealing with a somewhat older distribution, there is
always the possibility of encountering problems because we will be
recompiling openssh using the most recent versions of its build
dependencies.
[Original Description]
Please consider applying this change to openssh-server distributed in Xenial
(16.04).
Without it, sshd can sporadically hang when making use of the
`AuthorizedKeysCommand` option.
https://github.com/openssh/openssh-
portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1877454/+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
[Touch-packages] [Bug 1764044] Re: ssh-add asks about passphrases for keys already unlocked in the keychain
Thank you for following up with this. It seems like an interesting bug to consider, but it appears to be low priority, so I am marking it as such. On a side note, I would like to point out that these kind of bugs are usually better dealt with by upstream, so I would recommend you to file a report against them. If you do so, please let us know the link to the bug so that we can keep track of the progress. Thank you! ** Changed in: openssh (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1764044 Title: ssh-add asks about passphrases for keys already unlocked in the keychain Status in openssh package in Ubuntu: New Bug description: In the below example, on the second invocation of ssh-add I should not be prompted to enter the passphrase again after I successfully entered it on the first instance. This used to work fine in trusty i386 setup. $ keychain && ssh-add * keychain 2.8.2 ~ http://www.funtoo.org * Starting ssh-agent... Enter passphrase for /home/rolf/.ssh/id_rsa: Identity added: /home/rolf/.ssh/id_rsa (/home/rolf/.ssh/id_rsa) Enter passphrase for /home/rolf/.ssh/id_dsa: Identity added: /home/rolf/.ssh/id_dsa (/home/rolf/.ssh/id_dsa) $ keychain && ssh-add * keychain 2.8.2 ~ http://www.funtoo.org * Found existing ssh-agent: 25744 Enter passphrase for /home/rolf/.ssh/id_rsa: Identity added: /home/rolf/.ssh/id_rsa (/home/rolf/.ssh/id_rsa) Enter passphrase for /home/rolf/.ssh/id_dsa: Identity added: /home/rolf/.ssh/id_dsa (/home/rolf/.ssh/id_dsa) gnome-keyring is running: $ ps -ax|grep key 2067 ?SLl0:05 /usr/bin/gnome-keyring-daemon --start --components ssh 2078 ?Ssl0:01 /usr/lib/x86_64-linux-gnu/indicator-keyboard/indicator-keyboard-service --use-gtk 6987 ?S 0:00 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh 17832 pts/2S+ 0:00 grep --color=auto key ssh-agent is running: $ ps aux | grep ssh-agent leggewie 1928 0.0 0.0 15548 340 ?Ss 02:38 0:00 /usr/bin/ssh-agent /usr/bin/im-launch env LD_PRELOAD=libgtk3-nocsd.so.0 /usr/lib/gnome-session/run-systemd-session unity-session.target leggewie 6987 0.0 0.0 11304 1484 ?S02:50 0:00 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh leggewie 9952 0.0 0.0 11304 320 ?Ss 04:11 0:00 ssh-agent bash leggewie 17850 0.0 0.0 14492 1160 pts/2S+ 06:06 0:00 grep --color=auto ssh-agent $ env|grep SSH SSH_AUTH_SOCK=/tmp/ssh-W6fuGBztRRds/agent.6992 SSH_AGENT_PID=9952 SSH_AGENT_LAUNCHER=gnome-keyring To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1764044/+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
[Touch-packages] [Bug 1015819] Re: sb_sasl_generic_pkt_length: received illegal packet length when using Active Directory and ldapsearch and sasl with ssl or tls
** Changed in: cyrus-sasl2 (Ubuntu Cosmic) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1015819 Title: sb_sasl_generic_pkt_length: received illegal packet length when using Active Directory and ldapsearch and sasl with ssl or tls Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in cyrus-sasl2 source package in Bionic: Triaged Status in cyrus-sasl2 source package in Cosmic: Won't Fix Bug description: [Status] Awaiting upstream fix. [Workaround] Unknown. [Description] Not sure if this is a problem with openldap or cyrus-sasl2 at this point. Using sasl binding only works with ldapsearch when not using ssl or tls. If either ssl or tls is used I see this ouput from -d 1 from ldapsearch: sb_sasl_generic_pkt_length: received illegal packet length of 813957120 bytes sasl_generic_read: want=16, got=16 : 00 7e 02 01 00 78 84 00 00 00 5d 0a 01 02 04 00 .~...x]. sb_sasl_cyrus_decode: failed to decode packet: generic failure sb_sasl_generic_read: failed to decode packet ldap_read: want=8 error=Input/output error # numResponses: 0 ldap_result: Can't contact LDAP server (-1) tls_write: want=165 error=Connection reset by peer tls_write: want=165 error=Bad file descriptor To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/1015819/+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
[Touch-packages] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux
** Description changed:
+ [Impact]
+
+ When using openldap with sasl authentication, the slapd process will
+ communicate with the saslauthd daemon via a socket in
+ {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every Ubuntu
+ release from trusty onwards, because slapd's apparmor profile doesn't
+ contain the necessary directive to allow it to read/write from/to the
+ socket specified above.
+
+ The fix is simple: just add the necessary directive to allow slapd to
+ read/write from/to the saslauthd socket.
+
+ [Test Case]
+
+ One can reproduce the problem by doing:
+
+ $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
+ $ lxc shell openldap-bugbug1557157-groovy
+ # apt install slapd sasl2-bin ldap-utils apparmor-utils
+
+ (As the domain name, use "example.com").
+
+ # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
+ # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
+ mech_list: PLAIN
+ pwcheck_method: saslauthd
+ __EOF__
+ # adduser openldap sasl
+ # aa-enforce /etc/apparmor.d/usr.sbin.slapd
+ # systemctl restart slapd.service
+ # systemctl restart saslauthd.service
+ # passwd root
+
+ (You can choose any password here. You will need to type it when running
+ the next command.)
+
+ # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root -Y
+ PLAIN
+
+ The command will fail with something like:
+
+ ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
+ additional info: SASL(-1): generic failure: Password verification
failed
+
+ [Regression Potential]
+
+ This is an extremely simple and well contained fix, so I don't envision
+ any possible regressions after applying it. It is important noticing
+ that, since the problem affects older Ubuntu releases, the openldap
+ package will have to be rebuilt against possible newer versions of
+ libraries and other depencencies, which, albeit unlikely, may cause
+ issues.
+
+ [Original Description]
+
When using slapd with saslauthd the processes communicate via the
{,/var}/run/saslauthd/mux socket (this is the default location for the
saslauthd server from the sasl2-bin package in the
/etc/default/saslauthd config), but the apparmor profile for
usr.sbin.slapd does not allow access to this socket/file.
Syslog message:
apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd"
name="/run/saslauthd/mux" pid=1880
4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0
-
Please add the following line to /etc/apparmor.d/usr.sbin.slapd:
/{,var/}run/saslauthd/mux rw,
-
Ubuntu version: Ubuntu 14.04.4 LTS
slapd version: 2.4.31-1+nmu2ubu
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1557157
Title:
apparmor profile denied for saslauthd: /run/saslauthd/mux
Status in openldap package in Ubuntu:
Confirmed
Status in openldap source package in Trusty:
Confirmed
Status in openldap source package in Xenial:
Confirmed
Status in openldap source package in Bionic:
Confirmed
Status in openldap source package in Focal:
Confirmed
Status in openldap source package in Groovy:
Confirmed
Bug description:
[Impact]
When using openldap with sasl authentication, the slapd process will
communicate with the saslauthd daemon via a socket in
{,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
Ubuntu release from trusty onwards, because slapd's apparmor profile
doesn't contain the necessary directive to allow it to read/write
from/to the socket specified above.
The fix is simple: just add the necessary directive to allow slapd to
read/write from/to the saslauthd socket.
[Test Case]
One can reproduce the problem by doing:
$ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
$ lxc shell openldap-bugbug1557157-groovy
# apt install slapd sasl2-bin ldap-utils apparmor-utils
(As the domain name, use "example.com").
# sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
# cat > /etc/ldap/sasl2/slapd.conf << __EOF__
mech_list: PLAIN
pwcheck_method: saslauthd
__EOF__
# adduser openldap sasl
# aa-enforce /etc/apparmor.d/usr.sbin.slapd
# systemctl restart slapd.service
# systemctl restart saslauthd.service
# passwd root
(You can choose any password here. You will need to type it when
running the next command.)
# ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
-Y PLAIN
The command will fail with something like:
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: Password verification
failed
[Regression Potential]
This is an extremely simple and well contained fix, so I don't
envision any possible regressions after applying it. It is important
noticing that, since the problem affects older Ubuntu releases, the
[Touch-packages] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux
** Also affects: openldap (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: openldap (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: openldap (Ubuntu Groovy)
Importance: Undecided
Status: Incomplete
** Also affects: openldap (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: openldap (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: openldap (Ubuntu Trusty)
Status: Triaged => Confirmed
** Changed in: openldap (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: openldap (Ubuntu Focal)
Status: New => Confirmed
** Changed in: openldap (Ubuntu Groovy)
Status: Incomplete => Confirmed
** Changed in: openldap (Ubuntu Trusty)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
** Changed in: openldap (Ubuntu Xenial)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
** Changed in: openldap (Ubuntu Bionic)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
** Changed in: openldap (Ubuntu Focal)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
** Changed in: openldap (Ubuntu Groovy)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1557157
Title:
apparmor profile denied for saslauthd: /run/saslauthd/mux
Status in openldap package in Ubuntu:
Confirmed
Status in openldap source package in Trusty:
Confirmed
Status in openldap source package in Xenial:
Confirmed
Status in openldap source package in Bionic:
Confirmed
Status in openldap source package in Focal:
Confirmed
Status in openldap source package in Groovy:
Confirmed
Bug description:
When using slapd with saslauthd the processes communicate via the
{,/var}/run/saslauthd/mux socket (this is the default location for the
saslauthd server from the sasl2-bin package in the
/etc/default/saslauthd config), but the apparmor profile for
usr.sbin.slapd does not allow access to this socket/file.
Syslog message:
apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd"
name="/run/saslauthd/mux" pid=1880
4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0
Please add the following line to /etc/apparmor.d/usr.sbin.slapd:
/{,var/}run/saslauthd/mux rw,
Ubuntu version: Ubuntu 14.04.4 LTS
slapd version: 2.4.31-1+nmu2ubu
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+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
Re: [Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
On Monday, June 01 2020, Jamie Strandboge wrote:
> FYI, those re-runs passed and the package is green in
> https://people.canonical.com/~ubuntu-archive/pending-sru.html. When
> ubuntu-sru goes through the queue, this will be published.
Thanks for taking care of this one, Jamie!
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Title:
/proc/sys/kernel/random/boot_id rule missing from
abstractions/nameservice
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Focal:
Fix Committed
Bug description:
[Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
To fix this problem, we had to backport an upstream patch which adds
new directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported.
They are simple and self-contained, especially two of them, whose
purposes are to add the definition of the @{run} variable and then to
add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the
'nameservice' profile in order to let processes access (read-only)
files under "/run/systemd/userdb" and
"/proc/sys/kernel/random/boot_id". After thinking about the possible
cases, the only possible problem I could envision was for a program
that, not being able to access some of these files before, will now be
able to do that and therefore exercise a part of its codebase which
was not being used, possibly uncovering latent bugs in this software.
But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version
[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
** Merge proposal unlinked:
https://code.launchpad.net/~sergiodj/ubuntu/+source/apparmor/+git/apparmor/+merge/383796
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Title:
/proc/sys/kernel/random/boot_id rule missing from
abstractions/nameservice
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Focal:
Fix Committed
Bug description:
[Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
To fix this problem, we had to backport an upstream patch which adds
new directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported.
They are simple and self-contained, especially two of them, whose
purposes are to add the definition of the @{run} variable and then to
add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the
'nameservice' profile in order to let processes access (read-only)
files under "/run/systemd/userdb" and
"/proc/sys/kernel/random/boot_id". After thinking about the possible
cases, the only possible problem I could envision was for a program
that, not being able to access some of these files before, will now be
able to do that and therefore exercise a part of its codebase which
was not being used, possibly uncovering latent bugs in this software.
But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31
Re: [Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
On Wednesday, May 20 2020, Simon Déziel wrote:
> To save you some work, I'll be happy to do the verification as soon as
> something lands in focal-proposed. Thanks
Thanks, Simon! Much appreciated.
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Title:
/proc/sys/kernel/random/boot_id rule missing from
abstractions/nameservice
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Focal:
In Progress
Bug description:
[Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
To fix this problem, we had to backport an upstream patch which adds
new directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported.
They are simple and self-contained, especially two of them, whose
purposes are to add the definition of the @{run} variable and then to
add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the
'nameservice' profile in order to let processes access (read-only)
files under "/run/systemd/userdb" and
"/proc/sys/kernel/random/boot_id". After thinking about the possible
cases, the only possible problem I could envision was for a program
that, not being able to access some of these files before, will now be
able to do that and therefore exercise a part of its codebase which
was not being used, possibly uncovering latent bugs in this software.
But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu
Re: [Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
On Tuesday, May 19 2020, Jamie Strandboge wrote:
> @Sergio - assuming you are ok with my patch, do you still plan to follow
> through on the SRU verification once it is accepted into focal-proposed?
Hi Jamie,
Yes, I can take care of the verification if no one else does it.
Thanks,
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Title:
/proc/sys/kernel/random/boot_id rule missing from
abstractions/nameservice
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Focal:
In Progress
Bug description:
[Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
To fix this problem, we had to backport an upstream patch which adds
new directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported.
They are simple and self-contained, especially two of them, whose
purposes are to add the definition of the @{run} variable and then to
add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the
'nameservice' profile in order to let processes access (read-only)
files under "/run/systemd/userdb" and
"/proc/sys/kernel/random/boot_id". After thinking about the possible
cases, the only possible problem I could envision was for a program
that, not being able to access some of these files before, will now be
able to do that and therefore exercise a part of its codebase which
was not being used, possibly uncovering latent bugs in this software.
But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Re: [Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
On Tuesday, May 19 2020, Jamie Strandboge wrote:
> @Sergio, I didn't see that you uploaded anything to the queue so to
> expedite the SRU since there are a number of duplicates, I created a
> smaller backport of the fix and uploaded it to focal-proposed just now:
> http://launchpadlibrarian.net/480473812/apparmor_2.13.3-7ubuntu5_2.13.3-7ubuntu5.1.diff.gz
>
> (I hope that is alright).
Thanks, Jamie! That's quite alright. There's an MP opened about this,
but we got sidetracked and forgot to follow up.
Thanks again.
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Title:
/proc/sys/kernel/random/boot_id rule missing from
abstractions/nameservice
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Focal:
In Progress
Bug description:
[Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
To fix this problem, we had to backport an upstream patch which adds
new directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported.
They are simple and self-contained, especially two of them, whose
purposes are to add the definition of the @{run} variable and then to
add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the
'nameservice' profile in order to let processes access (read-only)
files under "/run/systemd/userdb" and
"/proc/sys/kernel/random/boot_id". After thinking about the possible
cases, the only possible problem I could envision was for a program
that, not being able to access some of these files before, will now be
able to do that and therefore exercise a part of its codebase which
was not being used, possibly uncovering latent bugs in this software.
But this is not a regression of apparmor per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
[Touch-packages] [Bug 1877454] Re: openssh-server hangs with AuthorizedKeysCommand
** Description changed:
[Impact]
On a default Xenial install, when sshd is configured to obtain the list
of allowed keys using AuthorizedKeysCommand (or the list of allowed
certificate principals using AuthorizedPrincipalsCommand), and if the
command pointed by Authorized{Keys,Principals}Command generates a lot of
output, sshd will hang while reading this same output. In a nutshell,
the problem happens when the subprocess generates enough data to fill
the pipe's buffer; in this scenario, sshd will wait(2) on the
subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
+ # chmod +x authkeyscommand.sh
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply, which
won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine whether
the subprocess exited correctly; and considering that this code is
written in C without the help of features like RAII and with the use of
goto statements, we are not able to disconsider the chances of making a
mistake and forgetting to free a resource or to properly read/write
from/to pipes, for example. This is, after all, the reason the bug
happened in the first place.
Having said that, openssh contains extensive tests and the code is well
organized and relatively easy to follow. Upon close inspection, there
doesn't seem to be an evident problem with the backported fixes.
As usual when dealing with a somewhat older distribution, there is
always the possibility of encountering problems because we will be
recompiling openssh using the most recent versions of its build
dependencies.
[Original Description]
Please consider applying this change to openssh-server distributed in Xenial
(16.04).
Without it, sshd can sporadically hang when making use of the
`AuthorizedKeysCommand` option.
https://github.com/openssh/openssh-
portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1877454
Title:
openssh-server hangs with AuthorizedKeysCommand
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Xenial:
Confirmed
Bug description:
[Impact]
On a default Xenial install, when sshd is configured to obtain the
list of allowed keys using AuthorizedKeysCommand (or the list of
allowed certificate principals using AuthorizedPrincipalsCommand), and
if the command pointed by Authorized{Keys,Principals}Command generates
a lot of output, sshd will hang while reading this same output. In a
nutshell, the problem happens when the subprocess generates enough
data to fill the pipe's buffer; in this scenario, sshd will wait(2) on
the subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
# chmod +x authkeyscommand.sh
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply,
which won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine
whether the subprocess exited correctly; and considering that this
code is written in C without the help of features like RAII and with
the use of goto statements, we are not able to disconsider the chances
of making a mistake and forgetting to free a resource or to properly
read/write from/to pipes, for example. This is, after all, the reason
the bug happened in the first place.
Having said that, openssh contains
[Touch-packages] [Bug 1877454] Re: openssh-server hangs with AuthorizedKeysCommand
** Description changed:
+ [Impact]
+
+ On a default Xenial install, when sshd is configured to obtain the list
+ of allowed keys using AuthorizedKeysCommand (or the list of allowed
+ certificate principals using AuthorizedPrincipalsCommand), and if the
+ command pointed by Authorized{Keys,Principals}Command generates a lot of
+ output, sshd will hang while reading this same output. In a nutshell,
+ the problem happens when the subprocess generates enough data to fill
+ the pipe's buffer; in this scenario, sshd will wait(2) on the
+ subprocess, which will be blocked trying to write the rest of the
+ output.
+
+ [Test Case]
+
+ In order to reproduce the bug, one can:
+
+ $ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
+ $ lxc shell openssh-server-bug1877454
+ # ssh-keygen
+ (no need to choose a passphrase for the key, just hit ENTER on all prompts)
+ # cat > authkeyscommand.sh << __EOF__
+ #!/bin/bash
+
+ cat /root/.ssh/id_rsa.pub
+ echo
+ head -c 1M < /dev/urandom
+ __EOF__
+ # cat >> /etc/ssh/sshd_config << __EOF__
+ AuthorizedKeysCommand /root/authkeyscommand.sh
+ AuthorizedKeysCommandUser root
+ __EOF__
+ # systemctl reload sshd.service
+ # ssh root@127.0.0.1
+
+ You will notice that ssh will stay there waiting for sshd's reply, which
+ won't come. The expected result would be for ssh to succeed.
+
+ [Regression Potential]
+
+ Since the affected code deals with executing a subprocess, reading its
+ output through a pipe, and then relying on wait(2) to determine whether
+ the subprocess exited correctly; and considering that this code is
+ written in C without the help of features like RAII and with the use of
+ goto statements, we are not able to disconsider the chances of making a
+ mistake and forgetting to free a resource or to properly read/write
+ from/to pipes, for example. This is, after all, the reason the bug
+ happened in the first place.
+
+ Having said that, openssh contains extensive tests and the code is well
+ organized and relatively easy to follow. Upon close inspection, there
+ doesn't seem to be an evident problem with the backported fixes.
+
+ As usual when dealing with a somewhat older distribution, there is
+ always the possibility of encountering problems because we will be
+ recompiling openssh using the most recent versions of its build
+ dependencies.
+
+ [Original Description]
+
Please consider applying this change to openssh-server distributed in Xenial
(16.04).
Without it, sshd can sporadically hang when making use of the
`AuthorizedKeysCommand` option.
https://github.com/openssh/openssh-
portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1877454
Title:
openssh-server hangs with AuthorizedKeysCommand
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Xenial:
Confirmed
Bug description:
[Impact]
On a default Xenial install, when sshd is configured to obtain the
list of allowed keys using AuthorizedKeysCommand (or the list of
allowed certificate principals using AuthorizedPrincipalsCommand), and
if the command pointed by Authorized{Keys,Principals}Command generates
a lot of output, sshd will hang while reading this same output. In a
nutshell, the problem happens when the subprocess generates enough
data to fill the pipe's buffer; in this scenario, sshd will wait(2) on
the subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply,
which won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine
whether the subprocess exited correctly; and considering that this
code is written in C without the help of features like RAII and with
the use of goto statements, we are not able to disconsider the chances
of making a mistake and forgetting to free a resource or to properly
read/write from/to pipes, for example. This is, after all, the reason
the bug happened in the first place.
Having said that, openssh contains extensive tests and the code is
well organized and relatively easy
[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
** Description changed:
[Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
# grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
- To fix
+ To fix this problem, we had to backport an upstream patch which adds new
+ directives to the 'nameservices' apparmor profile.
[Test Case]
In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
or, depending on how logging is configured:
$ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
[Regression Potential]
In order to fix this issue, 3 separate patches had to be backported.
They are simple and self-contained, especially two of them, whose
purposes are to add the definition of the @{run} variable and then to
add a trailing slash at the end of the "/run" pathname.
The other patch, albeit very simple, adds three statements to the
'nameservice' profile in order to let processes access (read-only) files
under "/run/systemd/userdb" and "/proc/sys/kernel/random/boot_id".
After thinking about the possible cases, the only possible problem I
could envision was for a program that, not being able to access some of
these files before, will now be able to do that and therefore exercise a
part of its codebase which was not being used, possibly uncovering
latent bugs in this software. But this is not a regression of apparmor
per se.
[Original Description]
(Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
- Installed: 2.13.3-7ubuntu4
- Candidate: 2.13.3-7ubuntu4
- Version table:
- *** 2.13.3-7ubuntu4 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
- 100 /var/lib/dpkg/status
+ Installed: 2.13.3-7ubuntu4
+ Candidate: 2.13.3-7ubuntu4
+ Version table:
+ *** 2.13.3-7ubuntu4 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
root@fb1:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
--
You received this bug notification because you are a member of
[Touch-packages] [Bug 1877454] Re: openssh-server hangs with AuthorizedKeysCommand
** Changed in: openssh (Ubuntu Xenial) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1877454 Title: openssh-server hangs with AuthorizedKeysCommand Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Xenial: Confirmed Bug description: Please consider applying this change to openssh-server distributed in Xenial (16.04). Without it, sshd can sporadically hang when making use of the `AuthorizedKeysCommand` option. https://github.com/openssh/openssh- portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1877454/+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
[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
** Description changed:
- # Description
+ [Impact]
On a default Focal install, systemd is used when looking up passwd and
group information:
- # grep systemd /etc/nsswitch.conf
+ # grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:
audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100
Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.
- # Steps to reproduce
+ To fix
+
+ [Test Case]
+
+ In order to reproduce the bug, one can:
1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1
2) setup apparmor inside the container (already done on official Ubuntu
images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
3) install bind9
$ lxc exec fb1 -- apt install bind9 -y
4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F
'profile="/usr/sbin/named"'
+ or, depending on how logging is configured:
- Step 4, should not return anything. Because systemd is involved in the
user/group lookups, it currently returns the following:
+ $ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"'
+
+ Step 4, should not return anything. Because systemd is involved in the
+ user/group lookups, it currently returns the following:
audit: type=1400 audit(1586826072.115:266): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
+ [Regression Potential]
+
+ In order to fix this issue, 3 separate patches had to be backported.
+ They are simple and self-contained, especially two of them, whose
+ purposes are to add the definition of the @{run} variable and then to
+ add a trailing slash at the end of the "/run" pathname.
+
+ The other patch, albeit very simple, adds three statements to the
+ 'nameservice' profile in order to let processes access (read-only) files
+ under "/run/systemd/userdb" and "/proc/sys/kernel/random/boot_id".
+ After thinking about the possible cases, the only possible problem I
+ could envision was for a program that, not being able to access some of
+ these files before, will now be able to do that and therefore exercise a
+ part of its codebase which was not being used, possibly uncovering
+ latent bugs in this software. But this is not a regression of apparmor
+ per se.
+
+ [Original Description]
+
+ (Description and Test Case were moved above)
# Workaround
1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs
# Additional information
root@fb1:~# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
*** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
root@fb1:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564
Title:
[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
** Changed in: apparmor (Ubuntu Focal) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1872564 Title: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice Status in apparmor package in Ubuntu: Fix Committed Status in apparmor source package in Focal: Confirmed Bug description: # Description On a default Focal install, systemd is used when looking up passwd and group information: # grep systemd /etc/nsswitch.conf passwd: files systemd group: files systemd Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial: audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information. # Steps to reproduce 1) launch a Focal container (named fb1 here) $ lxc launch images:ubuntu/focal fb1 2) setup apparmor inside the container (already done on official Ubuntu images) $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y 3) install bind9 $ lxc exec fb1 -- apt install bind9 -y 4) check kernel logs for DENIED $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"' Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following: audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 # Workaround 1) remove systemd from nsswitch.conf $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf 2) restart named $ lxc exec fb1 -- service named restart 3) notice no more denials in kernel logs # Additional information root@fb1:~# apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu4 Candidate: 2.13.3-7ubuntu4 Version table: *** 2.13.3-7ubuntu4 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@fb1:~# uname -a Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux root@fb1:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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
[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice
I'm building a PPA with the backported fix here: https://launchpad.net/~sergiodj/+archive/ubuntu/apparmor-bug1872564 ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1872564 Title: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice Status in apparmor package in Ubuntu: Fix Committed Bug description: # Description On a default Focal install, systemd is used when looking up passwd and group information: # grep systemd /etc/nsswitch.conf passwd: files systemd group: files systemd Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial: audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information. # Steps to reproduce 1) launch a Focal container (named fb1 here) $ lxc launch images:ubuntu/focal fb1 2) setup apparmor inside the container (already done on official Ubuntu images) $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y 3) install bind9 $ lxc exec fb1 -- apt install bind9 -y 4) check kernel logs for DENIED $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"' Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following: audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100 # Workaround 1) remove systemd from nsswitch.conf $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf 2) restart named $ lxc exec fb1 -- service named restart 3) notice no more denials in kernel logs # Additional information root@fb1:~# apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu4 Candidate: 2.13.3-7ubuntu4 Version table: *** 2.13.3-7ubuntu4 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@fb1:~# uname -a Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux root@fb1:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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
