[systemd-devel] [PATCH 2/2] udev: do NOT re-label smack

WaLyong Cho walyong.cho at samsung.com
Wed Aug 27 01:23:36 PDT 2014


On 08/27/2014 04:54 AM, Lennart Poettering wrote:
> On Tue, 26.08.14 21:52, Lennart Poettering (lennart at poettering.net) wrote:
> 
>>
>> On Thu, 21.08.14 12:58, WaLyong Cho (walyong.cho at samsung.com) wrote:
>>
>>> If selinux is disabled and smack is only enabled, smack label is
>>> relable-ed by label_fix. To avoid, make only be labeled for selinux.
>>> ---
>>>  src/udev/udev-node.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c
>>> index 6a9788b..00ade2c 100644
>>> --- a/src/udev/udev-node.c
>>> +++ b/src/udev/udev-node.c
>>> @@ -314,8 +314,8 @@ static int node_permissions_apply(struct udev_device *dev, bool apply,
>>>                  }
>>>  
>>>                  /* set the defaults */
>>> -                if (!selinux)
>>> -                        label_fix(devnode, true, false);
>>> +                if (!selinux && use_selinux())
>>> +                        mac_selinux_fix(devnode, true, false);
>>
>> Shouldn't mac_selinux_fix() simply become a NOP returning ENOTSUP if
>> selinux is disabled? Then, we can just invoke it here always, with no ill
>> effects...
> 
> Or actually, it shouldn't even return ENOTSUP, but simply 0... that's at
> least how the rest of the selinux code currently appears to work if
> selinux is off...

Yes, right.
And I just focused on SMACK only enabled case. In that case, the path is
re-labeled again by label_fix what include also
mac_smack_relabel_in_dev. Therefore the path was labeled twice. The
first was labeled correctly by mac_smack_path and the second was labeled
by mac_smack_relabel_in_dev. So all of /dev nodes were labeled "*" or
"_". So I made do only for selinux on there.

Is there any points should be modified?
>>
>>>                  if (!smack)
>>>                          mac_smack_path(devnode, NULL);
>>>          }
>>
>>
>> Lennart
>>
> 
> 
> Lennart
> 


WaLyong


More information about the systemd-devel mailing list