Bug 214377 - tcpdump gives 'permission denied' at 2nd file when dumping to >1 file
tcpdump gives 'permission denied' at 2nd file when dumping to >1 file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: tcpdump (Show other bugs)
4.4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-07 06:11 EST by Bas van der veen
Modified: 2007-11-16 20:14 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2007-0387
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 09:57:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bas van der veen 2006-11-07 06:11:21 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):
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:
Comment 1 Ralph Angenendt 2006-11-07 06:14:46 EST
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.
Comment 2 Ralph Angenendt 2006-11-07 06:22:15 EST
tcpdump-3.7.2-7.E3.5 from 3 U8 shows the same problems.
Comment 3 Ralph Angenendt 2006-11-07 07:33:29 EST
tcpdump-3.9.4-8.1 from FC6 works as expected, if that helps any further.
Comment 4 R P Herrold 2006-11-07 10:51:21 EST
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.
Comment 5 Ralph Angenendt 2006-11-07 11:12:32 EST
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.
Comment 6 Miroslav Lichvar 2006-11-08 07:22:27 EST
The FC6 version has a patch for this, see bug #176010. Workaround (with the
obvious drawback) is to use -Z root.
Comment 7 Ralph Angenendt 2006-11-09 05:38:54 EST
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).
Comment 8 Miroslav Lichvar 2006-11-09 06:02:04 EST
With the patch, tcpdump calls seteuid instead of setuid when -C option is used.
Comment 9 RHEL Product and Program Management 2007-05-09 04:57:33 EDT
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.
Comment 10 R P Herrold 2007-05-09 09:38:38 EDT
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
Comment 11 Miroslav Lichvar 2007-05-09 10:18:37 EDT
The update isn't done yet. If everything goes well, it'll be in 4.6 update.
Comment 14 Miroslav Lichvar 2007-05-29 11:50:31 EDT
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.
Comment 16 R P Herrold 2007-05-30 17:45:34 EDT
thanks
Comment 18 Jan Lieskovsky 2007-05-31 07:11:00 EDT
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 
Comment 20 Lubomir Kundrak 2007-06-12 10:35:47 EDT
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.
Comment 22 errata-xmlrpc 2007-11-15 09:57:34 EST
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

Note You need to log in before you can comment on or make changes to this bug.