Hi, Does the attached patch look better? I have fixed the sequence of xattr processing (now just after uid, gid, mode and etc.) + switched to use a list for collecting the xattrs. I think it is more generic to allow many xattrs to be set for one node, since it is normal use case.
Best Regards, Elena -----Original Message----- From: Kay Sievers [mailto:[email protected]] Sent: Wednesday, July 03, 2013 2:23 PM To: Reshetova, Elena Cc: Lennart Poettering; [email protected]; Ware, Ryan R; Schaufler, Casey; [email protected] Subject: Re: [systemd-devel] Patch for Smack labelling support in udev On Wed, Jul 3, 2013 at 1:04 PM, Reshetova, Elena <[email protected]> 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
0001-Adding-extended-attribute-support-for-udev-nodes-lab.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
