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

[Kay Sievers]

On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
<auke-jan.h.kok at intel.com> wrote:
> On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena <elena.reshetova at 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