On Tue, Aug 31, 2004 at 06:46:35PM +0200, Nigel Kukard wrote:
> 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.
oh, is it? uhm, why?
> 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
i _say_ might ... but then you mention that you've done exactly
the same policy mods that i had to...
> 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"
i think we need the input of more experienced people than us to
say why these associate things are needed.
> 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!!!!
ah, the joys of the "ItWorksForMe(tm)" approach...
>
> 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...
a correct implementation of the
hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
operation (mount with a new context which would otherwise need to be
achieved with two commands: mount followed by restorecon)
in my books, that's a good reason!
*shrug*... guess i have the totally oposite outlook
than you, i've had quite a number of my patches go mainstream though
dude, the entire selinux thing is disliked by stacks of debian
maintainers because of the knock-on implications it has.
imagine what chaos would ensue if up until now, linux only had
a FAT filesystem and someone said "hey, there's this _great_ concept
it's called file ownership and file permissions, i've invented
something called an ext2 filesystem".
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">
lkcl.net </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl(a)lkcl.net </a> <br />