On Wed, Jul 28, 2010 at 11:43, Lennart Poettering <[email protected]> wrote: > On Mon, 26.07.10 16:42, Daniel J Walsh ([email protected]) wrote: >> tcontext=system_u:object_r:device_t:s0 tclass=chr_file >> type=1400 audit(1280174589.476:7): avc: denied { read } for pid=1 >> comm="systemd" name="autofs" dev=devtmpfs ino=9482 >> scontext=system_u:system_r:init_t:s0 >> tcontext=system_u:object_r:device_t:s0 tclass=chr_file >> type=1400 audit(1280174589.476:8): avc: denied { read } for pid=1 >> comm="systemd" name="autofs" dev=devtmpfs ino=9482 >> scontext=system_u:system_r:init_t:s0 >> tcontext=system_u:object_r:device_t:s0 tclass=chr_file >> >> Lennart, we talked about this earlier. I think this is caused by the >> modprobe calls to create /dev/autofs. Since udev is not created at the >> point that init loads the kernel modules, the devices get created with >> the wrong label. Once udev starts the labels get fixed. >> >> I can allow init_t to read device_t chr_files. > > Hmm, I think a cleaner fix would be to make systemd relabel this device > properly before accessing it? Given that this is only one device this > should not be a problem for us to maintain, I think? How would the > fixing of the label work? Would we have to spawn restorecon for this, or > can we actually do this in C without too much work?
I guess we can just do what udev is doing, and call setfilecon(), with a context of an earlier matchpathcon(). Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
