On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H <auke-jan.h....@intel.com> wrote: > On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena <elena.reshet...@intel.com> > wrote:
>> For example, I can set a couple of smack-related xattrs in one go like >> XATTR{security.SMACK64}="*", XATTR{security.SMACK64EXEC}="*". >> Doesn't make sense from smack point of view (only smack64 is really >> meaningful >> on device nodes), but proves that functionality works. > > right, but we could be setting other non-SMACK xattrs now all in one > go - for example, SELINUX ones ("security.selinux"). Yeah, *looks* powerful, but also scary. :) And selinux is not managed by visible strings exposed to tools, it's all hidden in a library, and the database returns the stuff to apply. There should never be the need to set any string from selinux with a tool carrying static strings. > This looks OK to me, can you take another look at it? I still can't wrap my head around the issue that we can use udev rules now to *add* things which will never get removed again. If we add a rule that set one of these attributes, and remove the rule again, the applied xattr will never be cleared. It all sounds not right to me, and I don't think we should go ahead with anything like this before we have sorted out the responsibilities and ownership of data we attach to device nodes. We do not do that for anything else, things just don't pile up, they are reset, cleared when the config goes away and an event is triggered. We probably need some concept of ownership, based on xattr names or namespaces, soemthing that makes it clear who's responsible to reset/clear the attributes when the config changes. Not sure, maybe we can just reset all xattrs with an "add" event, and declare "add" as a form of reset to a prisitine state. The other issue is, that as nice as generic support for xattrs sounds, it might in the end not be what we should offer to "random" users. I really can't decide at this moment, I have to think it through. Thanks, Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel