-C flag not properly working on Fedora

[joubin]

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

[davidsnt]

Seeing the same issue on Fedora 21. Do we have any updates?

[msekletar]

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.

[infrastation]

This looks like a continuation of the discussion started in #388.

[infrastation]

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.

[guyharris]

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.

[guyharris]

# 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.

[guyharris]

[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.