|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001570||CentOS-4||Other||public||2006-11-07 08:51||2008-06-02 19:36|
|Product Version||4.4 - i386|
|Target Version||Fixed in Version||4.6|
|Summary||0001570: tpcdump stops with 'permission denied' error when dumping to multiple files|
|Description||tcpdump (14:3.8.2-10.RHEL4) on CentOS 4.4 i386 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.|
However, when the second file needs to be created, tcpdump stops with a 'permission denied' error, even when run as root in /root.
Has been reproduced on other 4.4 i386 boxes.
|Tags||No tags attached.|
Yes, I can confirm this on a) CentOS 4.4 and b) on RHEL 4 with the same version of tcpdump.
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.
This is clearly a bug from upstream which hasn't been reported there yet.
Do you want to open a bug report for that on bugzilla.redhat.com or do you want us to do that? :)
|Hi, I'll create a bugreport over there, np.|
|Please put a link to that in this bug report.|
Reported as bug 214377.
interesting -- 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.
(Copy of comment 5 in the RH-Bugzilla version of this bug)
|This bug has seen some (low) activity on upstream's bugzilla. Solution might be in CentOS 4.6 (Yes, I know that 4.5 isn't out yet) :)|
|2006-11-07 08:51||basv||New Issue|
|2006-11-07 08:51||basv||Status||new => assigned|
|2006-11-07 10:32||range||Note Added: 0004136|
|2006-11-07 10:32||range||Status||assigned => confirmed|
|2006-11-07 11:03||basv||Note Added: 0004137|
|2006-11-07 11:06||range||Note Added: 0004138|
|2006-11-07 11:12||basv||Note Added: 0004139|
|2006-11-07 15:50||herrold||Note Added: 0004141|
|2006-11-07 16:13||range||Note Added: 0004142|
|2007-05-09 09:24||range||Note Added: 0005129|
|2008-06-02 19:36||range||Status||confirmed => closed|
|2008-06-02 19:36||range||Note Added: 0007374|
|2008-06-02 19:36||range||Resolution||open => fixed|
|2008-06-02 19:36||range||Fixed in Version||=> 4.6|