Bug 850768

Summary:	tshark with -w option fails if file does not exist
Product:	Red Hat Enterprise Linux 7	Reporter:	Tomas Jamrisko <tjamrisk>
Component:	wireshark	Assignee:	Peter Hatina <phatina>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	fweimer, tsmetana
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-28 13:38:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tomas Jamrisko 2012-08-22 12:00:16 UTC

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):
wireshark-1.6.8-1.el7.x86_64


How reproducible:
always

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 12:30:16 UTC

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 4 Peter Hatina 2013-01-15 08:27:50 UTC

I added a newer version of the patch to upstream bugzilla: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7672

Patch: https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9797&action=diff&context=patch&collapsed=&headers=1&format=raw

Comment 5 Florian Weimer 2013-01-15 10:52:47 UTC

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