Bug 850768 - tshark with -w option fails if file does not exist
tshark with -w option fails if file does not exist
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: wireshark (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Peter Hatina
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2012-08-22 08:00 EDT by Tomas Jamrisko
Modified: 2016-05-31 21:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-28 08:38:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Jamrisko 2012-08-22 08:00:16 EDT
Description of problem:
tshark does not create a new file, if file specified with -w option does not exist, instead exits with 

tshark: The file to which the capture would be saved ("<file>") could not be opened: Permission denied.

and returns 1

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. tshark -i <interface> -w <file that does not yet exist>

Expected results:
File with the given name is created
Comment 1 Jan Safranek 2012-08-29 08:30:16 EDT
dumpcap utility gives up root privileges too early, before opening the output file. I sent a patch upstream: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7672
Comment 5 Florian Weimer 2013-01-15 05:52:47 EST
I suspect that you're trying to create a file in /root, and /root has 550 permissions.  That needs DAC override capabilities even with EUID=0, and we don't want to keep these (because they're strongly root-equivalent).

Workaround is to use:

# tshark -w - > /root/foo

I think this should be closed with WONTFIX.

In theory, it should be possible to use setresuid/setresgid to swap real and effective IDs, open the output file, swap them back (possibly regaining root privileges), and the continue as before (drop the unused capabilities etc.).

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