[Touch-packages] [Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child

2021-01-12 Thread Sergio Durigan Junior
** 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

2020-12-01 Thread Sergio Durigan Junior
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

2020-11-30 Thread Sergio Durigan Junior
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)

2020-11-27 Thread Sergio Durigan Junior
** 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)

2020-11-26 Thread Sergio Durigan Junior
** 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

2020-11-26 Thread Sergio Durigan Junior
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

2020-11-26 Thread Sergio Durigan Junior
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

2020-11-26 Thread Sergio Durigan Junior
** 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)

2020-11-24 Thread Sergio Durigan Junior
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)

2020-11-24 Thread Sergio Durigan Junior
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

2020-11-14 Thread Sergio Durigan Junior
@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

2020-11-13 Thread Sergio Durigan Junior
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

2020-11-02 Thread Sergio Durigan Junior
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"

2020-09-28 Thread Sergio Durigan Junior
** 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"

2020-09-28 Thread Sergio Durigan Junior
** 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"

2020-09-28 Thread Sergio Durigan Junior
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"

2020-09-28 Thread Sergio Durigan Junior
** 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

2020-09-16 Thread Sergio Durigan Junior
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

2020-09-04 Thread Sergio Durigan Junior
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

2020-09-04 Thread Sergio Durigan Junior
** 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

2020-09-04 Thread Sergio Durigan Junior
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

2020-09-02 Thread Sergio Durigan Junior
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

2020-09-01 Thread Sergio Durigan Junior
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)

2020-07-24 Thread Sergio Durigan Junior
** 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)

2020-07-14 Thread Sergio Durigan Junior
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

2020-07-03 Thread Sergio Durigan Junior
** 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

2020-06-25 Thread Sergio Durigan Junior
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

2020-06-24 Thread Sergio Durigan Junior
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

2020-06-22 Thread Sergio Durigan Junior
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

2020-06-16 Thread Sergio Durigan Junior
** 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

2020-06-15 Thread Sergio Durigan Junior
** 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

2020-06-12 Thread Sergio Durigan Junior
** 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

2020-06-01 Thread Sergio Durigan Junior
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

2020-05-22 Thread Sergio Durigan Junior
** 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

2020-05-20 Thread Sergio Durigan Junior
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

2020-05-20 Thread Sergio Durigan Junior
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

2020-05-19 Thread Sergio Durigan Junior
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

2020-05-13 Thread Sergio Durigan Junior
** 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

2020-05-13 Thread Sergio Durigan Junior
** 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

2020-05-13 Thread Sergio Durigan Junior
** 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

2020-05-12 Thread Sergio Durigan Junior
** 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

2020-05-12 Thread Sergio Durigan Junior
** 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

2020-05-12 Thread Sergio Durigan Junior
** 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

2020-05-08 Thread Sergio Durigan Junior
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