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
--
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web:
www.lbsd.net Email: nkukard(a)lbsd.net
Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395 Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions
The best language to use is the language that was designed for
what you want to use it for.