tcpdump
tcpdump copied to clipboard
the-tcpdump-group
-C flag not properly working on Fedora
Linux spock 3.19.3-200.fc21.x86_64 #1 SMP Thu Mar 26 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It will fail using the -C option to specify the file size.
[root@spock Desktop]# tcpdump --version tcpdump version 4.7.3 libpcap version 1.6.2 OpenSSL 1.0.1k-fips 8 Jan 2015 [root@spock Desktop]# tcpdump -i ens35u1 -C 100 -s0 -w - > tmp.pcap tcpdump: Couldn't change to 'tcpdump' uid=72 gid=72: Operation not permitted [root@spock Desktop]# tcpdump -i ens35u1 -C 100 -s0 -w tmp.pcap tcpdump: Couldn't change ownership of savefile [root@spock Desktop]# tcpdump -i ens35u1 -s0 -w tmp.pcap tcpdump: listening on ens35u1, link-type EN10MB (Ethernet), capture size 262144 bytes ^C47 packets captured 47 packets received by filter 0 packets dropped by kernel
Noted: in 244860 and 809638 in this
This is a known issue. In fedora by default tcdpump runs as user tcdpump (system user UID 72). If started with -C argument tcdpump will create first savefile (still running as root) but soon after that will drop root privileges. Hence it looses DAC override capability. Creation of next savefile fails because working directory of tcpdump process is not writable by others (most likely). To workaround this set ACL for tcpdump user on directory where you'd like to store savefiles.
This issue still stands and seems to have more aspects to it (tested on Fedora 32):
# pwd
/tmp
# tcpdump --version
tcpdump version 4.9.3
libpcap version 1.9.1 (with TPACKET_V3)
OpenSSL 1.1.1g FIPS 21 Apr 2020
# tcpdump -i enp0s3 -C 1 -s0 -w - > tmp.pcap
dropped privs to tcpdump
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
^C10569 packets captured
10575 packets received by filter
0 packets dropped by kernel
[root@localhost tmp]# ll
total 21256
-rw-r--r--. 1 tcpdump tcpdump 1000919 Jan 7 16:12 -1
-rw-r--r--. 1 tcpdump tcpdump 1001570 Jan 7 16:12 -10
-rw-r--r--. 1 tcpdump tcpdump 1000029 Jan 7 16:12 -11
-rw-r--r--. 1 tcpdump tcpdump 1003666 Jan 7 16:12 -12
-rw-r--r--. 1 tcpdump tcpdump 1000110 Jan 7 16:12 -13
-rw-r--r--. 1 tcpdump tcpdump 1000598 Jan 7 16:12 -14
-rw-r--r--. 1 tcpdump tcpdump 1001348 Jan 7 16:12 -15
-rw-r--r--. 1 tcpdump tcpdump 1000854 Jan 7 16:12 -16
-rw-r--r--. 1 tcpdump tcpdump 1002056 Jan 7 16:12 -17
-rw-r--r--. 1 tcpdump tcpdump 1002166 Jan 7 16:12 -18
-rw-r--r--. 1 tcpdump tcpdump 1000110 Jan 7 16:12 -19
-rw-r--r--. 1 tcpdump tcpdump 1001449 Jan 7 16:12 -2
-rw-r--r--. 1 tcpdump tcpdump 1000352 Jan 7 16:12 -20
-rw-r--r--. 1 tcpdump tcpdump 681531 Jan 7 16:12 -21
-rw-r--r--. 1 tcpdump tcpdump 1003057 Jan 7 16:12 -3
-rw-r--r--. 1 tcpdump tcpdump 1002004 Jan 7 16:12 -4
-rw-r--r--. 1 tcpdump tcpdump 1005128 Jan 7 16:12 -5
-rw-r--r--. 1 tcpdump tcpdump 1001161 Jan 7 16:12 -6
-rw-r--r--. 1 tcpdump tcpdump 1002140 Jan 7 16:12 -7
-rw-r--r--. 1 tcpdump tcpdump 1002433 Jan 7 16:12 -8
-rw-r--r--. 1 tcpdump tcpdump 1001817 Jan 7 16:12 -9
-rw-r--r--. 1 root root 1000783 Jan 7 16:12 tmp.pcap
# tcpdump -i enp0s3 -C 1 -s0 -w tmp.pcap
dropped privs to tcpdump
tcpdump: tmp.pcap: Permission denied
At least it mentions dropping the privileges now.
If started with -C argument tcdpump will create first savefile (still running as root) but soon after that will drop root privileges.
Please show the code path in which sudo privileges are dropped (by calling droproot()) after the first dump file is opened (by calling pcap_dump_open()). From examining the code, and from testing, that does not appear to be the case with the main branch or the 4.99 branch.
# tcpdump -i enp0s3 -C 1 -s0 -w - > tmp.pcap dropped privs to tcpdump tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes ^C10569 packets captured 10575 packets received by filter 0 packets dropped by kernel
As expected, of course; the shell from which tcpdump is running has root permissions, so it can create the tmp.pcap file.
# tcpdump -i enp0s3 -C 1 -s0 -w tmp.pcap dropped privs to tcpdump tcpdump: tmp.pcap: Permission denied
As expected - the root privileges are dropped before it tries to create the first capture file, starting in, as far as I can tell, tcpdump 4.0.
[root@spock Desktop]# tcpdump -i ens35u1 -C 100 -s0 -w - > tmp.pcap tcpdump: Couldn't change to 'tcpdump' uid=72 gid=72: Operation not permitted
That's probably some SELinux/AppArmor/whatever thingie preventing a process that's presumably running as root from changing its UID.
[root@spock Desktop]# tcpdump -i ens35u1 -C 100 -s0 -w tmp.pcap tcpdump: Couldn't change ownership of savefile
That's probably some version of tcpdump that is incorrectly creating the savefile before relinquishing privileges (or failing to relinquish privileges without reporting that), and then trying to change the ownership of the savefile to the user and failing to do so (either because it relinquished root privileges or because of the aforementioned SELinux/AppArmor/whatever stuff.
As far as I can tell, our 4.7.2 release should relinquish root privilege before trying to create the savefile. If it's not doing so, either somebody unimproved it by "helpfully" changing it to relinquish root privileges after creating the savefile, or something (SELinux/AppArmor/whatever?) is getting in the way.