On 8 April 2012 12:44, Sven Vermeulen <email@example.com> wrote: > Hmm, I can't seem to reproduce all you see, although I can see it is
> becoming quite messy nowadays. Is the /run mislabeling still a fact? What
> might be happening (although I can't confirm this here) is that your
> (unmounted) /run has no good label. The moment openrc mounts it (through
> /lib64/rc/sh/init.sh) the mount inherits the context, but it also means
> if you relabel, you are only relabeling the tmpfs (and not the real
> The label of the /run directory was wrong. I'll check later whether that
has fixed it (I don't really want to reboot now for that). It's strange as
I did the same trick with /proc, /sys etc. (copying whatever was set
through restorecon). The context was "system_u:var_run_t:file_t" > You can "solve" it by bindmounting your root file system, and then setting
> the context of /run (chcon -t var_run_t should suffice).
> The /dev is another issue. I currently don't have to deal with it as I'm
> forced to use an initramfs (as I have a separate /usr) so I need to relabel
> /dev anyhow before switching to enforcing mode :-( But I can imagine what
> happens... kdevtmpfs runs as kernel_t and creates device files in /dev
> (which are labeled device_t).
My system uses an initrd as well (as it has an lvm based root filesystem). >
> From what I read, udev is supposed to relabel the files. Although I can't
> confirm this, I also see that udev isn't the first thing that is started
> (and that, if it gets started in enforcing mode, it might already need a
> correctly labeled /dev when running without unconfined domains).
If you have some info that I could look at I'd like to help. I'm fairly new
at selinux and I still find it rather complex, but what better way to learn
it than to get your hands dirty ;-). Btw. This is a desktop system which
might provide its own interesting challenges.
Paul de Vrieze