tcpdump in lxd container: apparmor blocks writing to stdout/stderr

[Brian Candler]

[ Impact ]

Users that run tcpdump from an SSH session inside a container cannot
see the output because tcpdump tries to write to /dev/pts/, which is
not allowed by the AppArmor policy.

This upload fixes the bug by allowing read/write access to the devices
under /dev/pts/ in the AppArmor policy.

[ Test Plan ]

Create a lxd container. In this example we are using version 20.04,
but the issue is reproducible in all versions.

lxc launch ubuntu:20.04

SSH into the container and run the following command

tcpdump -i eth0 -nn not tcp port 22

In a different window, ping the IP of the container. Notice that
there's no output on the tcpdump window, even after you press Ctrl+C.

Check the kernel logs and you will see a DENIED message like the one
below

[ 575.438349] audit: type=1400 audit(1676055298.285:164): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-peaceful-rattler_<var-snap-lxd-common-lxd>" profile="/usr/sbin/tcpdump" name="/dev/pts/1" pid=7922 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=1000000 ouid=1000000

[ Where problems could occur ]

The SRU broadens the AppArmor policy for tcpdump, so if there was
ever an exploit on tcpdump that allowed a malicious agent to
write to /dev/pts/*, this could be used to write to the
terminal. With that said, the risk of this hapenning is low.

[ Other Info ]

The SRU for bionic, focal, jammy, kinetic and lunar can be found in
https://launchpad.net/~georgiag/+archive/ubuntu/lp1667016

Tcpdump from inside the container needs to be updated to use the
version with the fix in the AppArmor policy.

--------------------- ORIGINAL DESCRIPTION ----------------------

[ubuntu 16.04, lxd 2.0.8 or 2.0.9, tcpdump 4.7.4 or 4.9.0]

If you ssh into an lxd container as a normal user, and inside that container run "sudo tcpdump", the tcpdump process is blocked from writing to stdout/stderr. This appears to be due to apparmor: disabling apparmor for tcpdump makes the problem go away.

    ln -s /etc/apparmor.d/usr.sbin.tcpdump /etc/apparmor.d/disable/

Note: this is a different bug from #1641236. In that bug, the user did "lxc exec <container> bash" to get a shell in the container; the stdout fd was being passed from the outer host to the container. But in this case, the pty is being created entirely inside the container by sshd.

Details copied from https://github.com/lxc/lxd/issues/2930

# Steps to reproduce

1. Create two Ubuntu 16.04 lxd containers, one privileged, one not.
2. ssh into each one, and then use `sudo -s` to get root. (Do not use `lxc exec` because of issue #1641236)
3. Inside one run `tcpdump -i eth0 -nn not tcp port 22`, and ping from the other.

tcpdump in the privileged container works just fine.

tcpdump in the unprivileged container does not show any output. But if I run strace on it I see errors attempting to access stdout and stderr:

~~~
ioctl(1, TCGETS, 0x7fff97c8d680) = -1 ENOTTY (Inappropriate ioctl for device)
...
write(2, "tcpdump: verbose output suppress"..., 75) = -1 EACCES (Permission denied)
write(2, "listening on eth0, link-type EN1"..., 74) = -1 EACCES (Permission denied)
~~~

This is very weird. Even more weird: the following command *does* capture packets:

~~~
tcpdump -i eth0 -nn -w foo.pcap
~~~

The file foo.pcap grows. This proves it's nothing to do with network capture perms.

But the following command shows no output:

~~~
tcpdump -r foo.pcap -nn
~~~

And again it's because it can't write to stdout:

~~~
fstat(1, 0x7ffe2fb5eb10) = -1 EACCES (Permission denied)
read(3, "", 4096) = 0
write(1, "14:34:30.618180 IP6 fe80::c609:6"..., 1740) = -1 EACCES (Permission denied)
~~~

I had originally thought this was to do with capabilities. But if I run `capsh --print` inside both containers, they both have `cap_net_raw` and `cap_net_admin`. In fact, the unprivileged container has two additional capabilities! (`cap_mac_override` and `cap_mac_admin`)

So now I suspect that apparmor is at fault.

#### dmesg

dmesg output generated by the following steps:

* start tcpdump
* wait 5 seconds
* send 1 ping from other side
* wait 5 seconds
* stop tcpdump

~~~
[429020.685987] audit: type=1400 audit(1487774339.708:3597): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=100000 ouid=101001
[429020.686000] audit: type=1400 audit(1487774339.708:3598): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=100000 ouid=101001
[429020.686013] audit: type=1400 audit(1487774339.708:3599): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=100000 ouid=101001
[429020.686022] audit: type=1400 audit(1487774339.708:3600): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=100000 ouid=101001
[429020.716725] device eth0 entered promiscuous mode
[429020.741308] audit: type=1400 audit(1487774339.764:3601): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429020.741330] audit: type=1400 audit(1487774339.764:3602): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429021.716785] audit: type=1400 audit(1487774340.740:3603): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=100000 ouid=0
[429030.630448] audit: type=1400 audit(1487774349.652:3604): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630543] audit: type=1400 audit(1487774349.652:3605): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630555] audit: type=1400 audit(1487774349.652:3606): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630565] audit: type=1400 audit(1487774349.652:3607): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630574] audit: type=1400 audit(1487774349.652:3608): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630584] audit: type=1400 audit(1487774349.652:3609): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630593] audit: type=1400 audit(1487774349.652:3610): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_<var-lib-lxd>" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=100000 ouid=0
[429030.630687] device eth0 left promiscuous mode
~~~

#### privileged container

~~~
$ lxc config show srv1-campus1
name: srv1-campus1
profiles:
- br-cnd11
config:
  security.privileged: "true"
  volatile.base_image: 315bedd32580c3fb79fd2003746245b9fe6a8863fc9dd990c3a2dc90f4930039
  volatile.eth0.hwaddr: 00:16:3e:25:c5:bf
  volatile.idmap.base: "0"
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
devices:
  root:
    path: /
    type: disk
ephemeral: false

root@srv1:~# capsh --print
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_syslog,cap_wake_alarm,cap_block_suspend,37
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
~~~

#### unprivileged container

~~~
$ lxc config show srv2-campus1
name: srv2-campus1
profiles:
- br-cnd11
config:
  volatile.base_image: 315bedd32580c3fb79fd2003746245b9fe6a8863fc9dd990c3a2dc90f4930039
  volatile.eth0.hwaddr: 00:16:3e:33:9c:29
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  root:
    path: /
    type: disk
ephemeral: false

root@srv2:~# capsh --print
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
~~~

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Seth Arnold (seth-arnold)]

Top-notch bug report :) Thanks!

[Brian Candler (b-candler)]

I believe this bug has been wrongly marked as a duplicate of #1641236. I described in the second paragraph of the bug report why this is *not* a duplicate.

#1641236 is when lxc exec passes an open pty from the host to the container.

This bug (#1667016) is specifically when the pty is opened within the container, by connecting to sshd inside the container.

See also: https://github.com/lxc/lxd/issues/2930

[Brian Candler (b-candler)]

The duplicate status of this bug is still wrong.

A workaround has been provided at https://github.com/lxc/lxd/issues/2930#issuecomment-1418752618

Inside the container:

### Ubuntu 18.04, 20.04
echo "/dev/pts/* rw," >/etc/apparmor.d/local/usr.sbin.tcpdump
systemctl reload apparmor

### Ubuntu 22.04
echo "/dev/pts/* rw," >/etc/apparmor.d/local/usr.bin.tcpdump
systemctl reload apparmor

[Georgia Garcia (georgiag)]

I agree that this issue is not a duplicate of Bug 1641236 and it can be fixed by adding rw access to /dev/pts/*, which is not the case for the other bug.

[Andreas Hasenack (ahasenack)]

Just a nitpick on the patch comment:

+ # allow printing to stdout/stderr when inside a container
+ # (LP: #1667016)
+ /dev/pts/* rw,

This is allowing rw to /etc/pts/* in *all* cases, not just when inside a container :)

[Andreas Hasenack (ahasenack)]

Hello Brian, or anyone else affected,

Accepted tcpdump into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tcpdump/4.99.1-4ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Hello Brian, or anyone else affected,

Accepted tcpdump into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tcpdump/4.99.1-3ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Hello Brian, or anyone else affected,

Accepted tcpdump into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tcpdump/4.9.3-4ubuntu0.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Hello Brian, or anyone else affected,

Accepted tcpdump into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tcpdump/4.9.3-0ubuntu0.18.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Candler (b-candler)]

> This is allowing rw to /etc/pts/* in *all* cases, not just when inside a container :)

True enough. For me it raises the question: why is this required in a container, but not in a "normal" host or VM?

[Georgia Garcia (georgiag)]

I believe this happens because, based on the following audit log,

AVC apparmor="AUDIT" operation="exec" info="ix fallback" profile="lxd-x_</var/snap/lxd/common/lxd>" name="/usr/bin/tcpdump" pid=154814 comm="bash" requested_mask="x" fsuid=1000000 ouid=1000000 target="lxd-x_</var/snap/lxd/common/lxd>"

lxd opens the file descriptor for stdout and stderr, and when tcpdump is executed, the container profile transitions to the tcpdump profile. AppArmor then reevaluates all opened fds, to check if the current task still has access to it. More implementation details here:
https://gitlab.com/apparmor/apparmor-kernel/-/blob/apparmor-next/security/apparmor/file.c#L638
https://gitlab.com/apparmor/apparmor-kernel/-/blob/apparmor-next/security/apparmor/file.c#L597

Since the policy for tcpdump did not have explicit access to stdout/stderr, they are blocked from reading/writing.
This does not happen in a normal host or VM because whichever program executes tcpdump (bash for example), is usually unconfined, so the fds are not reevaluated.

[Trent Lloyd (lathiat)]

Is there a reason for hardcoding /dev/pts instead of:
#include <abstractions/consoles>

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted tcpdump (4.9.3-0ubuntu0.18.04.3) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

stenographer/unknown (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#tcpdump

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Chris Halse Rogers (raof)]

Is there a fix for lunar pending for this? It looks like bionic->kinetic are ready to release, just waiting on a fix in Lunar.

[Georgia Garcia (georgiag)]

Yes, there is. There's an autopkgtest failure for xdp-tools [lunar/amd64] which does not seem to be related to the change.

[Gianfranco Costamagna (costamagnagianfranco)]

Hello, why isn't this bug opened in Debian?

[Andreas Hasenack (ahasenack)]

> Hello, why isn't this bug opened in Debian?

I would guess because debian didn't even have LXD until recently[1]

1. https://tracker.debian.org/news/1361535/accepted-lxd-500-1-source-amd64-into-unstable/

[Andreas Hasenack (ahasenack)]

Can we get someone looking at the xdp-tools/amd64 failure[1] in lunar? Or at least file a bug about it? There have been ton of retries already, but it keeps failing.

1. https://autopkgtest.ubuntu.com/packages/x/xdp-tools/lunar/amd64 https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/x/xdp-tools/20230301_194524_0e221@/log.gz

[Brian Candler (b-candler)]

Tested with jammy lxd container, proposed patch works WFM.

(Note that a simple "lxc launch images:ubuntu/22.04/cloud" does not exercise this issue, because this minimal image does not install apparmor; but installing "ubuntu-server" does make the problem appear, and then the fixes to apparmor/tcpdump in -proposed make the problem go away)

I can also confirm that using
#include <abstractions/consoles>
works, as per comment #13. That gives very slightly wider permissions, shown in /etc/apparmor.d/abstractions/consoles

[Brian Candler (b-candler)]

> I would guess because debian didn't even have LXD until recently[1]
>
> 1. https://tracker.debian.org/news/1361535/accepted-lxd-500-1-source-amd64-into-unstable/

Ooh, nice: a platform with lxd packaged as deb, not snap!

That could be enough to make me migrate from Ubuntu to Debian :-)

[Gianfranco Costamagna (costamagnagianfranco)]

ok but can we open a Debian bug w. patch now? lxd was uploaded one year ago, if apparmor support is broken, its not a good reason to keep delta w.r.t. Debian, right?

[Brian Candler (b-candler)]

Looks like lxd is in bookworm/testing only. But I guess it would be OK to raise a bug against tcpdump in bookworm, if you can reproduce this in a pure Debian system.

[Georgia Garcia (georgiag)]

Andreas, I created bug 2009063 for the autopkgtest failure. Combining all of the test runs, all tests pass at one point or another, which makes me think that it is not related to this change.

[Georgia Garcia (georgiag)]

Verification done. I added evidence of the test working and the package version here: https://pastebin.canonical.com/p/t6FfF9GC3V/

[Launchpad Janitor (janitor)]

This bug was fixed in the package tcpdump - 4.99.1-4ubuntu0.1

---------------
tcpdump (4.99.1-4ubuntu0.1) kinetic; urgency=medium

  * debian/usr.sbin.tcpdump: allow tcpdump printing to stdout/stderr when
    running from a container (LP: #1667016)

 -- Georgia Garcia <email address hidden> Fri, 10 Feb 2023 15:15:53 -0300

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for tcpdump has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package tcpdump - 4.99.1-3ubuntu0.1

---------------
tcpdump (4.99.1-3ubuntu0.1) jammy; urgency=medium

  * debian/usr.sbin.tcpdump: allow tcpdump printing to stdout/stderr when
    running from a container (LP: #1667016)

 -- Georgia Garcia <email address hidden> Fri, 10 Feb 2023 15:14:22 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package tcpdump - 4.9.3-4ubuntu0.2

---------------
tcpdump (4.9.3-4ubuntu0.2) focal; urgency=medium

  * debian/usr.sbin.tcpdump: allow tcpdump printing to stdout/stderr when
    running from a container (LP: #1667016)

 -- Georgia Garcia <email address hidden> Fri, 10 Feb 2023 08:34:14 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package tcpdump - 4.9.3-0ubuntu0.18.04.3

---------------
tcpdump (4.9.3-0ubuntu0.18.04.3) bionic; urgency=medium

  * debian/usr.sbin.tcpdump: allow tcpdump printing to stdout/stderr when
    running from a container (LP: #1667016)

 -- Georgia Garcia <email address hidden> Fri, 10 Feb 2023 15:11:16 -0300

[Andreas Hasenack (ahasenack)]

I verified the attached logs and am satisfied that they show the executed planned test case, and that the results are correct.

The package built correctly in all architectures and Ubuntu releases it was meant for.

There are no DEP8 regressions, or they were fixed.

There is no SRU freeze ongoing at the moment.

There is no halted phasing on the previous update.

[Junien F (axino)]

Big thanks to everyone involved for resolving this very irritating bug !

[Launchpad Janitor (janitor)]

This bug was fixed in the package tcpdump - 4.99.3-1ubuntu1

---------------
tcpdump (4.99.3-1ubuntu1) lunar; urgency=medium

  * debian/usr.sbin.tcpdump: allow tcpdump printing to stdout/stderr when
    running from a container (LP: #1667016)

 -- Georgia Garcia <email address hidden> Fri, 10 Feb 2023 15:17:18 -0300

[Gianfranco Costamagna (costamagnagianfranco)]

@georgiag can you please followup on the Debian bug?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032298