On May 19, 2017, at 08:47, Robin Humble <rjh+lus...@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+lus...@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 _______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
