From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0 Description of problem: tcpdump 3.8.2-10 used with -C and -W switches like so: tcpdump -e -i eth0 -n -s 1518 -vv -C 1 -W 1000 -w trace.cap should generate trace.cap000, trace.cap001 and so on. When the second file needs to be created, tcpdump stops with a 'permission denied' error, even when run as root in /root. Version-Release number of selected component (if applicable): tcpdump-3.8.2-10 How reproducible: Always Steps to Reproduce: Just run the command above on several 4.4 machines and it is reproducable. Actual Results: Expected Results: The additional files should have been created. Additional info:
stracing that command gives me: open("trace.cap000", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4 for the first trace file and open("trace.cap001", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied) for the second file. Hmm? Reproducible on RHEL4 U4.
tcpdump-3.7.2-7.E3.5 from 3 U8 shows the same problems.
tcpdump-3.9.4-8.1 from FC6 works as expected, if that helps any further.
nteresting -- I think it is an issue that root UID priv's are being dropped once it is in capture mode running the test in /var/tmp/, it works ... sort of: -rw-r--r-- 1 root root 1000079 Nov 7 10:46 trace.cap000 -rw-r--r-- 1 pcap pcap 1000130 Nov 7 10:46 trace.cap001 -rw-r--r-- 1 pcap pcap 1000852 Nov 7 10:47 trace.cap002 -rw-r--r-- 1 pcap pcap 738370 Nov 7 10:47 trace.cap003 the file creation is not being done in the UID in which it was started, ownership to 'pcap' may be part of a security matter which I am not immediately aware of ... I initially ran it in a root squashed NFS export, and the dump could not run (as root is forbidden to create files). It is unclear to me that this is an improper behaviour, as my workaround seems to be effective; it would clearly be preferred for there to be a single owner of these files, clearly.
It looks like this is "the Problem". From the manual page: -Z Drops privileges (if root) and changes user ID to user and the group ID to the primary group of user. This behavior can also be enabled by default at compile time. You cannot get tcpdump to tell you *which* flags it was compiled with. But by looking at the .spec file I found this: pushd %tcpdump_dir unset CFLAGS %define optflags $RPM_OPT_FLAGS -DIP_MAX_MEMBERSHIPS=20 %configure --enable-ipv6 --with-user=pcap So yes, it was compiled in at install time. Though I'm still wondering why the first package trace is opened *before* tcpdump drops its privileges. Some kind of Documentation in the package pertaining to this would be great.
The FC6 version has a patch for this, see bug #176010. Workaround (with the obvious drawback) is to use -Z root.
Do I understand that patch correctly? tcpdump regains euid 0 for opening the files in the ring buffer? I'd vote for consistency here: Either open all files as the user tcpdump was compiled with (meaning: Drop uid 0 *before* opening the *first* file in the buffer and complain with a sane error message if the user pcap cannot write there) or implement the patch from bug #176010. At least somehow get rid of that inconsistency at the moment (where tcpdump will fail when trying to reopen the first buffer).
With the patch, tcpdump calls seteuid instead of setuid when -C option is used.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Miroslav This is a simple and trivial fix -- Rel Eng has sat on this for six months now HOW can we get this applied? -- Russ herrold
The update isn't done yet. If everything goes well, it'll be in 4.6 update.
It will be fixed the other way. If -C option is specified, root privileges will be dropped before the first file is opened. All files will have pcap owner and the user has to start tcpdump in a directory where pcap has write permissions.
thanks
After discussion with the maintainer, the new approach is this one: 1, There is note in the new tcpdump man page: "Note that when used with -Z option (enabled by default), privileges are dropped before opening first savefile." so it is expected, that tcpdump doesn't create the "trace.cap000" file. 2, The "-Z root" option should be used to force "tcpdump" to create desired trace.cap files. From man pages: -Z Drops privileges (if root) and changes user ID to user and the group ID to the primary group of user. This behavior is enabled by default (-Z pcap), and can be disabled by -Z root. -> PASS
Closing this bug. We are not going to fix this, for we believe that the behavor is not errorneous. It is advised that either the directory where traffic logs go is writable by pcap user, or user specified with -Z option. Please note that using -Z root when logging traffic from an untrusted network is not a good idea because in case the tcpdump process is compromised due to a security bug, the attacker could obtain superuser privileges instead of ones of an unprivileged user.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0387.html