you have patched the program udev (0.030-10?)
[and yes, i would highly recommend sending it to the list(s) to make it clear what you mean].
this patch will run, when it starts up, a call to setfilecon() on /dev (or /udev, or whatever the mount point of the devfs is).
and _just_ on "/dev".
yes?
correct
and it's done BEFORE any inodes are EVER created in the new /dev, yes?
correct
assuming yes, then it kinda-solves the need for doing that hacked-up relaxed-constraints-patch-to-hooks.c fscontext= option.
aha, u correct!!!!
why? because you can mount -t tmpfs /dev blah blah and you don't care what the context is because udev will set the correct one when it runs.
perfect!!!!, so that solves the need for the hooks patch, which is in actual fact wrong.
that is - of course - assuming that file_contexts/file_contexts _contains_ the correct file context for /dev.
*nod*
it might make (i dunno) for a simpler policy.
yep
what i mean is, have you had to add in the modifications to the selinux policy that i sent to the lists last week?
e.g. these:
allow udev_tbl_t device_t:filesystem { associate }; allow initctl_t device_t:filesystem { associate };
and these:
+# needed for udev-mounted (/dev) tmpfs +allow $1_tty_device_t device_t:filesystem { associate }; + +# to allow users to run df on udev-mounted (/dev) tmpfs +allow $1_t device_t:filesystem { getattr }; + #EXE=/bin/df NAME=/ : getattr +
had to add quite a couple more, but i'm still working on that to make it "correct"
these are all there for reasons i cannot entirely fathom but it starts, in types/file.te, with this:
allow { device_type } device_t:filesystem associate;
i need this aswell.... which is very interesting, so my "way of doing it" doesn't solve this problem. i'll keep looking for the solution
which is all because of this:
mount tmpfs -o fscontext=system_u:object_r:device_t /dev
this doesn't cause the problem, its something else
anyway what i am saying is that if you HAVE NOT got all these patches in your selinux policy files, then your approach has distinct advantages: less mods to the policy files and less differences between a persistent and non-persistent udev filesystem.
correct, i'm still working on it though and it HAS TO BE COMPLETED SOON!!!!
other than that, my intuition is saying "i don't like it" and what that means is that in about two or three weeks i will be able to articulate clearly and precisely why i don't think it's a good idea.
*shrug*, just a different outlook, patching userspace instead of kernel space
it'll likely be something to do with your solution being a two-step operation whereas the hacked-up-relaxed-fscontext-hooks.c things is a one-step (atomic?) operation.
kernel developers will very much not like to get patches unless for a very good reason... *shrug*... guess i have the totally oposite outlook than you, i've had quite a number of my patches go mainstream though
l.
-Nigel