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@xxxxxxxx";> lkcl@xxxxxxxx </a> <br />
