On Sun, Aug 22, 2004 at 09:25:38PM +1000, Russell Coker wrote:
It seems that udev is now virtually mandatory as of the latest
rawhide update.
udev uses ramfs for /tmp, ramfs (as of the latest Fedora kernel 2.6.8-1.525)
has no support for file labelling and breaks everything.
Can we get ramfs labelling working in the next few days or do we have to
change things to not depend on udev?
chris pebenito of gentoo/hardened i believe has written a ramfs patch
already (2.6.6)
it was what i based the shmfs one off of.
or maybe that's the other way round, i dunno. can't remember.
remember that just getting ramfs / tmpfs working is not enough, you
must also:
- patch selinux/hooks.c to allow mount -o fscontext=system_u:object_r:device_t
on a tmpfs or shmfs or add an extra option to hooks.c _similar_ to
fscontext but without the bit that says "stop if this filesystem
supports xattrs".
- modify /etc/init.d/udev to then mount /dev with the default context
of device_t which whill FAIL if you DO NOT patch hooks.c as above:
mount -n -o
fscontext=system_u:object_r:device_t,size=$tmpfs_size,mode=0755
-t tmpfs none /dev
- add in an equivalent of my extra post-udev-and-hotplug duplicate of
/etc/init.d/modutils that will load things like nvidia, ppp_generic
and stuff that are not yet fully 2.6-compliant drivers (i.e. they
don't grok /sys and consequently don't generate hotplug events) .
i assume that rawhide, given that it is using udev already, is
perfectly capable of doing a proper and far superior job to what
i have hacked up.
- run a restorecon on ALL DEVICE NODES CREATED PRIOR TO /etc/init.d/udev
RUNNING.
i got bored of doing this regularly and manually and so wrote a
small script (/sbin/restoredevicefiles) which does this for me.
badly. it uses ls (really must use commands NOT from /usr and must
use commands that DO NOT a require /dev/null or access to /dev/fd/*)
i believe i had to copy cut from /usr/bin/cut to /bin/cut (!!) hey
there are probably people out there who could do this as c-code
or with sed or something more appropriate, to be honest i haven't
got time to DoItRight(tm) so the ItWorksForMe(tm) approach is fine
for me until _someone else_ does the DoItRight(tm) approach.
- udev, udevd _and_ udevsend (_why_ is udev split into three separate
programs??????) _all_ need to be hacked up to run setfiles -q -s on a
pipe which udev(d?) will communicate the name of the inode to.
russell advised me that using popen would be suitable for this:
however i am not sure whether it should be put in udev or in
udevd and i haven't the TimeRightNow(tm) to focus on
MakingItNice(tm)
alternatively, a patch (also attached) to add selinux "restorecon"
stuff to udevsend is included which, although it still has a 1/4
second delay per inode added, at least works.
patch is against udev-0.030. udev-0.030 has had the
/etc/udev.d/default/selinux script removed which is a complete pain
but hey, if linux-hotplug-devel say it don't work, it don't work.
it's taken me about three maybe four weeks to get this hacked up to
a working / reasonably acceptable (for me at least) point.
i'm assuming that you would like the kernel patches: if you would like
me to place a copy of my hacked-up policy files at
hands.com/~lkcl/selinux
please let me know because they are not very pretty but will save you a
lot of time: because i don't know any better it has taken me somewhere
in excess of 100 reboots to get a working udev-tmpfs-enabled policy
plus initscripts hacks.
if someone can inform me of the appropriate cvs-based diff
command that will allow me to include fs/ramfs/xattr.c
and fs/ramfs/xattr-security.c in the patch i would be most
grateful, otherwise people will just have to manually blat
those two files (attached) into the appropriate locations.
i'd _really_ appreciate it if people _could_ say "hey, yes, we
really need tmpfs-enabled udev in fc" because then i wouldn't
have so much crap hanging around on my debian/selinux system:
i'd far rather it had already been done and i could have
copied or relied on the work of more experienced individuals.
l.