[systemd-devel] Systemd is causing mislabeled devices to be created and then attempting to read them.

Kay Sievers kay.sievers at vrfy.org
Wed Jul 28 02:57:24 PDT 2010


On Wed, Jul 28, 2010 at 11:43, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 26.07.10 16:42, Daniel J Walsh (dwalsh at redhat.com) 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


More information about the systemd-devel mailing list