On 27/11/07 18:49, Christopher J. PeBenito wrote:
> On Mon, 2007-11-26 at 15:45 +0100, Václav Ovsík wrote:
>> Hi,
>> Debian Etch, refpolicy HEAD, udev produces during startup (udevsettle)
>> wile creating symlinks into /dev/disk/by-uuid/...
>> following:
>>
>> audit(1195744042.060:3): avc: denied { relabelfrom } for pid=836 comm="udevd" name="44517f56-2445-4330-bce7-5168aa534c1c" dev=tmpfs ino=1646 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=lnk_file
>> audit(1195744042.060:4): avc: denied { relabelto } for pid=836 comm="udevd" name="44517f56-2445-4330-bce7-5168aa534c1c" dev=tmpfs ino=1646 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=lnk_file
>>
>> Attached patch solves this.
>> Can be merged into refpolicy please?
>
> This is interesting, it isn't seen on other distros. Perhaps it has to
> do with the way debian sets up tmpfs /dev before udev starts?
I get similar messages: note that the contexts being relabelled from and to
are the same.
I had a look, and the symlinks are created by udev running in the initramfs,
then the tmpfs /dev is mount --moved into the main root. No labelling is
done yet because no policy has been loaded. Then when the main udev starts
up it replays the coldplug events. When it comes to create the symlink
again, it notices that it is already there and calls lsetfilecon.
Should udev or libselinux be checking whether it will be relabelling files
to their existing label? And indeed, it's not clear to me why udev should
be calling lsetfilecon on existing symlinks at all.
--
Martin Orr
Attachment:
signature.asc
Description: OpenPGP digital signature
