> 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@xxxxxxxx
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.
Attachment:
pgp5O07SRwIAk.pgp
Description: PGP signature
