Bug 753969

Summary:	sandbox says "Failed to create runtime temporary directory"
Product:	[Fedora] Fedora	Reporter:	amturnip
Component:	policycoreutils	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	dwalsh, mgrepl, thoger
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-11-23 16:40:05 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description amturnip 2011-11-15 00:40:13 UTC

Description of problem:

Instead of running firefox, sandbox gives an error message (in which I have substituted $USER for my username):

Error: /tmp/.sandbox-$USER-rIzLKM not owned by UID 0
Failed to create runtime temporary directory

From run to run, the last leg of the temporary name varies, but the message always says, "... not owned by UID 0".


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

$ rpm -q kernel firefox policycoreutils policycoreutils-python policycoreutils-sandbox 
kernel-3.1.0-7.fc16.x86_64
kernel-3.1.1-1.fc16.x86_64
firefox-7.0.1-3.fc16.x86_64
policycoreutils-2.1.4-3.fc16.x86_64
policycoreutils-python-2.1.4-3.fc16.x86_64
policycoreutils-sandbox-2.1.4-3.fc16.x86_64

$ uname -r
3.1.1-1.fc16.x86_64

$ id -u
2001


How reproducible:

  Consistently.

Steps to Reproduce:
1. /usr/bin/sandbox -X -t sandbox_web_t -W /usr/bin/metacity /usr/bin/firefox
  
Actual results:

Error: /tmp/.sandbox-$USER-rIzLKM not owned by UID 0
Failed to create runtime temporary directory

Expected results:

  A window full of Firefox.

Comment 1 Daniel Walsh 2011-11-15 14:28:11 UTC

Is there anything special about your /tmp directory?

ls -ld /tmp
drwxrwxrwt. 14 root root 1040 Nov 15 08:55 /tmp/
ls -lZd /tmp/
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp/

Comment 2 amturnip 2011-11-16 00:30:51 UTC

My /tmp directory agrees with your ls readings...  Here's "mount" output too:

$ ls -ld /tmp
drwxrwxrwt. 44 root root 4096 Nov 15 18:47 /tmp

$ ls -lZd /tmp/
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp/

$ mount | grep /tmp
/dev/mapper/bla-bla on /tmp type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)

Comment 3 Daniel Walsh 2011-11-18 18:34:59 UTC

Tomas any ideas?

Comment 4 amturnip 2011-11-19 02:32:28 UTC

It appears to be working now with policycoreutils-2.1.4-6 (and numerous other updated packages that I do not suppose are relevant). 

$ rpm -q kernel firefox policycoreutils policycoreutils-python policycoreutils-sandbox 
kernel-3.1.0-7.fc16.x86_64
kernel-3.1.1-1.fc16.x86_64
firefox-7.0.1-3.fc16.x86_64
policycoreutils-2.1.4-6.fc16.x86_64
policycoreutils-python-2.1.4-6.fc16.x86_64
policycoreutils-sandbox-2.1.4-6.fc16.x86_64

$ uname -r
3.1.1-1.fc16.x86_64

$ id -u
2001

Comment 5 Tomas Hoger 2011-11-21 09:23:03 UTC

I only reproduced this after removing fscaps (or at least cap_setuid).  That apparently makes setfsuid(0) fail.  Probably a non-suid and no-fscap seunshare on reporter's system?

Comment 6 amturnip 2011-11-22 01:36:54 UTC

Having updated policycoreutils to 2.1.4-6: the cap_setuid is there and the sandbox works as I expect.  I can't tell what the program file's attributes were before the update to 2.1.4-6.

$ getcap /usr/sbin/seunshare
/usr/sbin/seunshare = cap_dac_override,cap_fowner,cap_setuid,cap_setpcap,cap_sys_admin,cap_sys_nice+ep