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.
