Red Hat Bugzilla – Bug 214377
tcpdump gives 'permission denied' at 2nd file when dumping to >1 file
Last modified: 2007-11-16 20:14:54 EST
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):
Steps to Reproduce:
Just run the command above on several 4.4 machines and it is reproducable.
The additional files should have been created.
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
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:
%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
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.
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.
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.