[lustre-discuss] seclabel

[Dilger, Andreas]

On May 19, 2017, at 08:47, Robin Humble <rjh+lustre at cita.utoronto.ca> wrote:
> 
> Hi Sebastien,
> 
> On Wed, May 17, 2017 at 02:37:31PM +0000, Sebastien Buisson wrote:
>> Le 17 mai 2017 à 16:16, Robin Humble <rjh+lustre at cita.utoronto.ca> a écrit :
>>> I took a gander at the source and noticed that llite/xattr.c
>>> deliberately filters out 'security.capability' and returns 0/-ENODATA
>>> for setcap/getcap, which is indeed what strace sees. so setcap/getcap
>>> is never even sent to the MDS.
>>> 
>>> if I remove that filter (see patch on lustre-devel) then setcap/getcap
>>> works ->
> ...
>>> 'b15587' is listed as the reason for the filtering.
>>> I don't know what that refers to.
>>> is it still relevant?
>> b15587 refers to the old Lustre Bugzilla tracking tool:
>> https://projectlava.xyratex.com/show_bug.cgi?id=15587
>> 
>> Reading the discussion in the ticket, supporting xattr at the time of Lustre 1.8 and 2.0 was causing issues on MDS side in some situations. So it was decided to discard security.capability xattr on Lustre client side. I think Andreas might have some insight, as he apparently participated in b15587.
> 
> my word that's a long time ago...
> I don't see much in the way of jira tickets about getxattr issues on
> MDS in recent times, and they're much more heavily used these days, so
> I hope that particular problem has long since been fixed.
> 
> should I open a jira ticket to track re-enabling of security.capabilities?

I don't recall the details of b=15587 off the top of my head, but the high-level issue is
that the security labels added a significant performance overhead, since they were retrieved
on every file access, but not cached on the client, even if most systems never used them.

Seagate implemented the client-side xattr cache for Lustre 2.5, so this should work a lot
better these days.  I'm not 100% positive if we also cache negative xattr lookups or not,
so this would need some testing/tracing to see if it generates a large number of RPCs.

> 
>> In any case, it is important to make clear that file capabilities, the feature you want to use, is completely distinct from SELinux.
>> On the one hand, Capabilities are a Linux mechanism to refine permissions granted to privileged processes, by dividing the privileges traditionally associated with superuser into distinct units (known as capabilities).
>> On the other hand, SELinux is the Linux implementation of Mandatory Access Control.
>> Both Capabilities and SELinux rely on values stored into file extended attributes, but this is the only thing they have in common.
> 
> 10-4. thanks.
> 
> 'ls --color' requests the security.capability xattr so this would
> be heavily accessed. do you think this is handled well enough currently
> to not affect performance significantly?

Good old "ls --color".  The support for statx() _just_ got into the kernel after 10 years
of trying, so that in another 5 years once "ls" is updated and in distros, then "ls --color"
will not do an extra RPC for each file to get the file permission to color a file differently
based on the executable status.

I guess if this xattr is cached from open time (or negative cached if missing), then this
wouldn't add significant overhead for a local getxattr call.  It should be possible to turn
on RPC tracing with "lctl set_param debug=+rpctrace" and count the RPCs for some operations
with the patch applied and removed, and see what the differences are.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation