Hide Forgot
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.
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/
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)
Tomas any ideas?
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
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?
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