Bug 448439

What actually creates the file system?

Not sure the best way to fix this.

What actually creates the file system?
# ls -laZ /tmp
drwxrwxrwt  root root system_u:object_r:file_t:s0      .
drwxr-xr-x  root root system_u:object_r:root_t:s0      ..
drwx------  joachim users unconfined_u:object_r:file_t:s0  gconfd-joachim
drwxrwxrwt  joachim users unconfined_u:object_r:file_t:s0  .ICE-unix
drwx------  joachim users unconfined_u:object_r:file_t:s0  keyring-SLt0Rd
drwx------  root root system_u:object_r:file_t:s0      lost+found
,,,

# grep '^/' /etc/mtab
/dev/mapper/system-fedora / ext3 rw 0 0
/tmp /tmp none rw,bind 0 0
/dev/mapper/ctmp /tmp ext2 rw,noexec 0 0
...

Note: since /tmp is encrypted by a random key, its ext2 filesystem is created
when it is mounted after boot.

I have found a simple workaround to get xguest working again: I've added the
following command to /etc/rc.local:
at now + 1 minutes << END
/sbin/restorecon -r /tmp
END

The direct call of restorecon in /etc/rc.local does not work and lets the mount
of encrypted /tmp partition fail. Therefore I guess it's not a problem of the
selinux policy but of the upstart process.

In Fedora 8 the same configuration had worked fine. The problem appeared after
the upgrade to Fedora 9.

Could you add a mount command to the rc.local to see what is mounted when you
run the restorecon command?

This is not an SELinux bug, I am reassigning to upstart for now.

(In reply to comment #3)
> Could you add a mount command to the rc.local to see what is mounted when you
> run the restorecon command?
> 
*** I've added the following commands to rc.local:
logger -t 'mounted when calling rc.local' `mount`
logger -t 'security context of tmp partition' `ls -ldZ /tmp`

*** This is the result. At this point, the crypto volume /dev/system/ctmp is
apparently not mounted:
May 29 20:58:36 machtnix mounted when calling rc.local:
/dev/mapper/system-fedora on / type ext3 (rw) proc on /proc type proc (rw) sysfs
on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs
on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw) /tmp on /tmp type none (rw,bind) /var/tmp on /var/tmp type none (rw,bind)
/home/xguest on /home/xguest type none (rw,bind) sunrpc on
/var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) fusectl on /sys/fs/fuse/connections
type fusectl (rw)
May 29 20:58:36 machtnix security context of tmp partition: drwxrwxrwt root root
system_u:object_r:tmp_t:s0 /tmp
May 29 20:58:36 machtnix setroubleshoot: SELinux prevented mount from mounting
on the file or directory "/tmp/sh-thd-1212058248" (type "initrc_tmp_t"). For
complete SELinux messages. run sealert -l b0ac6a1c-c998-41d9-932a-c40f9f690ee6
May 29 20:58:36 machtnix NetworkManager: <info>  starting...


*** The Raw Audit Messages of the AVC error are:
host=machtnix type=AVC msg=audit(1212087516.123:10): avc:  denied  { write } for
 pid=2468 comm="mount" path="/tmp/sh-thd-1212058248" dev=dm-3 ino=229384
scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0
tclass=file

host=machtnix type=SYSCALL msg=audit(1212087516.123:10): arch=40000003
syscall=11 success=yes exit=0 a0=9972ed0 a1=9972e40 a2=9972908 a3=0 items=0
ppid=2467 pid=2468 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/bin/mount"
subj=system_u:system_r:mount_t:s0 key=(null)

sealert gives the advice to fix the problem by command: 
  setsebool -P allow_mount_anyfile=1

But this has no effect for the reported problem (it just prevents the logged AVC
error).

So this looks like rc.local is not the final thing that upstart does.  The
question is whether assuming /etc/rc.local is run after the entire init process
is complete is a correct assumption.

*** This bug has been marked as a duplicate of 238437 ***

Created attachment 308015 [details]
Script called by incrontab to fix security context after mounting /tmp 

Script is intended only as a means to analyze the problem cause and as a quick
workaround.

(In reply to comment #6)
> 
> *** This bug has been marked as a duplicate of 238437 ***

I don't agree this problem is a duplicate of bug 238437. 

The encrypted /tmp partition is actually mounted on Fedora9, though not at the
time when rc.local is called, but about 10 seconds later after finishing
Network(Manager) initializations and before gdm is started. As mentioned in
238437, this seems to me the correct behaviour because init/upstart has to wait
for RNG initialization. The only problem on my system is that the /tmp directory
gets the wrong security context after mounting - causing problems with the new
gdm and xguest. 

I've written a modified workaround using incrontab (the idea is to call a
callback script "on_mount" after each mount and umount):

incrontab entry:
/etc/mtab IN_CLOSE_WRITE /usr/local/bin/on_mount

When the encrypted tmp partition /dev/mapper/ctmp is mounted, my script calls
logs the new mount entry, the current security context of the /tmp dir and then
restorecon to fix the security context:

Jun  2 22:59:29 machtnix mount called by rc.local: /dev/mapper/system-fedora /
ext3 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts
devpts rw,gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs rw 0 0 none
/proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 /tmp /tmp none rw,bind 0 0 /var/tmp
/var/tmp none rw,bind 0 0 /home/xguest /home/xguest none rw,bind 0 0 sunrpc
/var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 fusectl /sys/fs/fuse/connections
fusectl rw 0 0
Jun  2 22:59:29 machtnix security context of tmp partition: drwxrwxrwt root root
system_u:object_r:tmp_t:s0 /tmp
...
Jun  2 22:59:38 machtnix NetworkManager: <info>  Activation (eth1) Stage 5 of 5
(IP Configure Commit) complete.
Jun  2 22:59:38 machtnix mounted: > /dev/mapper/ctmp /tmp ext2 rw,noexec 0 0
Jun  2 22:59:39 machtnix /tmp context: drwxrwxrwt root root
system_u:object_r:file_t:s0 . drwxr-xr-x root root system_u:object_r:root_t:s0
.. drwx------ root root system_u:object_r:file_t:s0 lost+found
Jun  2 22:59:39 machtnix after restorecon: drwxrwxrwt root root
system_u:object_r:tmp_t:s0 . drwxr-xr-x root root system_u:object_r:root_t:s0 ..
drwx------ root root system_u:object_r:lost_found_t:s0 lost+found
Jun  2 22:59:40 machtnix gconfd (gdm-2640): (Version 2.22.0) wird gestartet,
Prozesskennung 2640, Benutzer »gdm«

Ok, I tend to agree that you did hit the other bug in question but this isn't
really a dupe.  The issue is that tmpfs has full support for extended
attributes.  With 'normal' filesystems when anaconda creates them anaconda gives
the root inode the correct selinux label for whereever it is going to be
mounted.  And say if you later create your own persistent fs that fs is going to
have 'file_t' until you mount it and label it the first time.

In this case since you can't save a persistant label for tmpfs all of the above
fails.  My suggestion would be to add

rootcontext=system_u:object_r:tmp_t:s0

in /etc/fstab.  Since you are creating this FS every time you need to label it
every time.  Admittedly I haven't tried this under an encrypted tmpfs, but this
is needed to get proper labeling with a non-encrypted tmpfs mounted on /tmp....

(In reply to comment #9)

> My suggestion would be to add
> 
> rootcontext=system_u:object_r:tmp_t:s0
> 
> in /etc/fstab.  
Thanks for your helpful explanation. I've followed the advice and it works fine.
I think, your suggestion is the final solution to my reported problem.