On Tue, Aug 31, 2004 at 07:02:52AM +0200, Nigel Kukard wrote:
> > you mean on /dev, i presume?
>
> yep, or /udev (configured in the udev config file)
oh.
yes.
redhat :)
> >
> > well i had to patch selinux/hooks.c to allow this [on a tmpfs]
> > by relaxing the criteria of the "fscontext=" option for mount.
> >
>
> if its tmpfs, this would void the requirement of passing a mount option
> fscontext, udev would set the correct context when started up (a check
> could also be added to do this only if the mount point is /dev and its
> tmpfs... *shrug*)
>
> > otherwise it's not _possible_ t set the context on /dev as it is
> > mounted [on a tmpfs].
> >
> > [if /dev was a persistent filesystem everything would be hunky-dory
> > and this wouldn't be an issue].
> >
>
> *nod*
>
> >
> > with that in mind, it's more that because you're putting device
> > inodes into a non-persistent filesystem, you end up getting the
> > "default" rules and so you must "restore" the contexts, or
> > you must patch udev to "understand" the contents of
> > /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
> > and setfscreatecon() from libselinux) such that it will create
> > inodes with the right file context.
> >
>
> I applied the patch to tmpfs to make it store xattr attributes which i
> found on the mailing list, seems your patch forgets xattr.h?
?? oops.
okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
and when i posted copies to the list i must have missed it out.
if you _do_ know how to properly create patches that other people
can apply simply, that'd be great.
> I also applied the patch which adds "matchpathcon()" &
> "setfscreatecon()" support,
dan is working on a new version of that, for udev-0.030-10.
> and modified udev to set the correct
> context of its root_path on startup.
mount -o fscontext=system_u:object_r:device_t yes?
did you patch selinux/hooks.c to relax the constraints on
the fscontext= parameter to allow the correct context to be
correctly applied? :)
> > ... but that's not how udev works: it deletes and creates inodes
> > on demand; nothing exists at boot-time, it's all created on-demand.
>
> at boot time i have about 5 devices in /dev with correct contexts set,
> udev them mounts tmpfs over this, WorksForMe(tm)
>
> so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
> persistent or non-persistent filesystem
yep.
> >
> > so, not only must udev be patched to restore contexts but also
> > the policies and various hacks added to "cope" with /dev being
> > incredibly basic at startup - prior to udev running.
>
> i have a simple persistent /dev which is used before udev runs, udev is
> then initialized, mounts a tmpfs over /dev (and restores its context)
oh. ah.... you _restore_ its context (i.e. run restorecon
/dev), you don't mount it with the modified mount -o fscontext=
parameter?
> just
> after sysctl -p is run in my initscripts so its basically one of the
> first things to run.
yep.
> Seeing as my initial /dev is on a persistent
> filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete,
upgrade or otherwise modify the "old" /dev [which you will find is
remounted --rbind to /.dev].
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev
and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire
/.dev gets relabelled to something completely useless: root_t
or default_t. i think it's default_t.
consequently your next reboot in enforcing mode will fail because
/sbin/init tries to access /dev/null and /dev/initctl etc. as
default_t ... and it can't.
should you choose to deal with this, replace /u?dev with /[\.u]dev or
some suitable regexp that i haven't a clue how to write so i just
did /.?u?dev and that did the trick.
the only _other_ thing you might find is that things like dialup
don't or won't have been loaded.
so i had to add in a _second_ version of /etc/init.d/modutils which
does exactly the same as /etc/init.d/modutils ... but with a different
list of modules, and AFTER udev has been run, not before.
the list i have so far in /etc/modules.postudev contains (for my purposes):
ppp_generic
nvidia
sg
ppp_generic is there because "pon provider" bitches about /dev/ppp
not existing
sg is there because of usb-mount using sg_mod: if the module is
pre-loaded, then /dev/sg0 gets created by udev.
i don't believe that these modules should be loaded prior to udev
being run: maybe they can, maybe they can't, maybe the nodes being
loaded prior will result in a pending hotplug event such that when
udev is run, the node gets created.
... but certainly, _some_ modules haven't been modified to conform
to the new /sys thing.
the "trick" of a node in /dev existing, and its first access
automatically triggering a modprobe... well that only works if
the node is there, and of course with udev, it isn't.
perhaps there should be a "hook" into tmpfs to be able to pass
filenames accessed in /dev on to udev, such that udev can go
"oo, they tried to access /dev/ppp, let's kick off that module,
then".
l.
|
