[systemd-devel] Patch for Smack labelling support in udev

Kay Sievers kay at vrfy.org
Wed Jul 3 04:23:25 PDT 2013


On Wed, Jul 3, 2013 at 1:04 PM, Reshetova, Elena
<elena.reshetova at intel.com> wrote:

>>Things like:
>>  ..., XATTR{foo}="foo", XATTR{bar}="bar"
>>would just eat the entire foo key. That is intentional? We usually have lists
>>for that, or we would not allow 2 keys ...
>
> Hm.. Do we want to allow multiple xattr setup on the same node?

I don't know. But we need to sure what we want and document it that way. :)

> I guess this
> can make sense if for example one is to setup the security label and another
> one some other attribute.
> So, I guess then it has to be stored in a list. I will take a look on how it
> is done for other cases.
> Could you please point to the right example on how such case is handled in
> udev (maybe from other permissions or attributes)? Some particular case that I
> should take as an example?

udev_list_entry_add(&event->run_list, ...

and quite a few other examples.

>>If pairs of values that belong to each other are allocated, we better check
>>if we run into allocation problems. Udev ignores that in some places and goes
>>ahead as the value would not have been set at all. But with pairs, we should
>>not end up with inconsistent pairs which have only the name or the value set.
>>The:
>>  if ((xattr_name) && (xattr_label))
>>should then just become:
>>  if (xattr_name)
>
> OK, and then I guess I would need to check during parcing that they are both
> set correctly and unset the other one, if one is missing, right?

Yeah, it's pretty simple: just always leave a clean state, or give up
where the error happens. Do leave invalid/partial data around and try
to cope with it later.

Kay


More information about the systemd-devel mailing list