Your message dated Sat, 28 Feb 2026 09:39:52 +0000 (UTC) with message-id <[email protected]> and subject line Re: AppArmor profile for tcpdump breaks default output buffering mode when tcpdump is executed in non-default network name spaces has caused the Debian Bug report #1081793, regarding AppArmor profile for tcpdump breaks default output buffering mode when tcpdump is executed in non-default network name spaces to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1081793: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081793 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: tcpdump Version: 4.99.3-1 Recently, I noticed that 'tcpdump' cannot use per-line buffering by default when it is executed in non-default network namespaces. For example, when it is executed in the following ways: -----BEGIN CLI----- $ sudo ip netns exec net0 tcpdump -ni veth0 # or $ sudo ip netns exec net0 bash # tcpdump -ni veth0 -----END CLI----- When the first packet arrives, 'tcpdump' tries to check if the standard output is a terminal, and while doing this, it tries to read the attributes of the related pts device. However, AppArmor blocks such calls: Aug 31 14:41:24 localhost audit[6350]: AVC apparmor="DENIED" operation="getattr" class="file" info="Failed name lookup - disconnected path" error=-13 profile="tcpdump" name="dev/pts/10" pid=6350 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=102 ouid=0 I tried to extend the default profile for tcpdump by allowing access to pts devices: -----BEGIN CLI----- # cat /etc/apparmor.d/local/usr.bin.tcpdump /dev/pts/[0-9]* r, # apparmor_parser -Q --debug /etc/apparmor.d/usr.bin.tcpdump | grep pts Mode: complain Mode: r:r Name: (/dev/pts/[0-9]*) -----END CLI----- ... but it did not work. Also, it does not help if I move the profile into the complain mode; the audit log shows that the call is ALLOWED, but in fact, AppArmor still blocks the call (checked with strace): -----BEGIN CLI----- Aug 31 14:53:05 localhost audit[6366]: AVC apparmor="ALLOWED" operation="getattr" class="file" info="Failed name lookup - disconnected path" error=-13 profile="tcpdump" name="dev/pts/10" pid=6366 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=102 ouid=0 # ps -efZ | grep tcpdump | grep -v grep tcpdump (complain) tcpdump 6391 6337 0 14:58 pts/10 00:00:00 tcpdump -ni veth0 icmp # aa-status apparmor module is loaded. 7 profiles are loaded. 6 profiles are in enforce mode. /usr/bin/man lsb_release man_filter man_groff nvidia_modprobe nvidia_modprobe//kmod 1 profiles are in complain mode. tcpdump 0 profiles are in kill mode. 0 profiles are in unconfined mode. 1 processes have profiles defined. 0 processes are in enforce mode. 1 processes are in complain mode. /usr/bin/tcpdump (6391) tcpdump 0 processes are unconfined but have a profile defined. 0 processes are in mixed mode. 0 processes are in kill mode. # strace output showing that the access is still blocked newfstatat(1, "", 0x7ffe927d5be0, AT_EMPTY_PATH) = -1 EACCES (Permission denied) -----END CLI----- Finally, I loaded the latest stable kernel 6.10.6 from the backports, but it did not help either: -----BEGIN CLI----- # uname -a Linux localhost 6.10.6+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.6- 1~bpo12+1 (2024-08-26) x86_64 GNU/Linux -----END CLI----- I can only overcome the issue when I: 1. unload the 'tcpdump' profile completely; 2. modify the 'tcpdump' profile with the debug flag "attach_disconnected"; or 3. execute a second 'sshd' instance in the non-default network namespace, in which I run 'tcpdump', and ssh to that context directly to execute 'tcpdump'. After reading this thread [1] about name space specifics and some other threads about the "Failed name lookup - disconnected path" error, I suspect that AppArmor blocks the aforementioned tcpdump's call because sshd, running in the default NS context, and tcpdump, running in the non-default NS context, also have '/dev/pts' mount in different FS contexts. For example: -----BEGIN CLI----- # grep pts /proc/`ps -ef | grep tcpdump | grep -v grep | awk '{print $2}'`/mountinfo 437 436 0:23 / /dev/pts rw,nosuid,noexec,relatime master:3 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 # grep pts /proc/1/mountinfo 26 25 0:23 / /dev/pts rw,nosuid,noexec,relatime shared:3 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 -----END CLI----- I also posted the description of the problem to the AppArmor mailing list [2] recently. Thank you. Garri [1] https://lists.ubuntu.com/archives/apparmor/2018-July/011718.html [2] https://alioth-lists.debian.net/pipermail/pkg-apparmor-team/2024-September/004204.html
--- End Message ---
--- Begin Message ---On Sat, 14 Sep 2024 22:57:20 +0200 Garri Djavadyan <[email protected]> wrote: > Package: tcpdump > Version: 4.99.3-1 > > > Recently, I noticed that 'tcpdump' cannot use per-line buffering by > default when it is executed in non-default network namespaces. For > example, when it is executed in the following ways: > > -----BEGIN CLI----- > $ sudo ip netns exec net0 tcpdump -ni veth0 > > # or > > $ sudo ip netns exec net0 bash > # tcpdump -ni veth0 > -----END CLI----- > > > When the first packet arrives, 'tcpdump' tries to check if the standard > output is a terminal, and while doing this, it tries to read the > attributes of the related pts device. However, AppArmor blocks such > calls: > > Aug 31 14:41:24 localhost audit[6350]: AVC apparmor="DENIED" > operation="getattr" class="file" info="Failed name lookup - > disconnected path" error=-13 profile="tcpdump" name="dev/pts/10" > pid=6350 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=102 > ouid=0 > > > I tried to extend the default profile for tcpdump by allowing access to > pts devices: > > > -----BEGIN CLI----- > # cat /etc/apparmor.d/local/usr.bin.tcpdump > /dev/pts/[0-9]* r, > > # apparmor_parser -Q --debug /etc/apparmor.d/usr.bin.tcpdump | grep pts > Mode: complain > Mode: r:r Name: (/dev/pts/[0-9]*) > -----END CLI----- > > ... but it did not work. > > > Also, it does not help if I move the profile into the complain mode; > the audit log shows that the call is ALLOWED, but in fact, AppArmor > still blocks the call (checked with strace): > > -----BEGIN CLI----- > Aug 31 14:53:05 localhost audit[6366]: AVC apparmor="ALLOWED" > operation="getattr" class="file" info="Failed name lookup - > disconnected path" error=-13 profile="tcpdump" name="dev/pts/10" > pid=6366 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=102 > ouid=0 > > # ps -efZ | grep tcpdump | grep -v grep > tcpdump (complain) tcpdump 6391 6337 0 14:58 > pts/10 00:00:00 tcpdump -ni veth0 icmp Yahoo Mail: Search, Organize, Conquer
--- End Message ---
