[lustre-discuss] seclabel

[Robin Humble]

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?

>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?

setxattr would be minimal and not performance critical, unlike with eg.
selinux and creat.

cheers,
robin