2017-08-23 02:13 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001570CentOS-4Otherpublic2008-06-02 19:36
Reporterbasv 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Product Version4.4 - i386 
Target VersionFixed in Version4.6 
Summary0001570: tpcdump stops with 'permission denied' error when dumping to multiple files
Descriptiontcpdump (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.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0004136

range (administrator)

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? :)

~0004137

basv (reporter)

Hi, I'll create a bugreport over there, np.

~0004138

range (administrator)

Please put a link to that in this bug report.

~0004139

basv (reporter)

Reported as bug 214377.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214377

~0004141

herrold (reporter)

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.

~0004142

range (administrator)

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.

(Copy of comment 5 in the RH-Bugzilla version of this bug)

~0005129

range (administrator)

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) :)

~0007374

range (administrator)

http://rhn.redhat.com/errata/RHSA-2007-0387.html
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History