[lustre-discuss] seclabel

[Sebastien Buisson]

Hi Robin,

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.

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.

Cheers,
Sebastien.

> Le 17 mai 2017 à 16:16, Robin Humble <rjh+lustre at cita.utoronto.ca> a écrit :
> 
> I setup a couple of VMs with 2.9 clients and servers (ldiskfs) and
> unfortunately setcap/getcap still are unhappy - same as with my
> previous 2.9 clients with 2.8 servers (ZFS).
> 
> hmm.
> 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 ->
> 
> # df .
> Filesystem            1K-blocks  Used Available Use% Mounted on
> 10.122.1.5 at tcp:/test8   4797904 33992   4491480   1% /mnt/test8
> # touch blah
> # setcap cap_net_admin,cap_net_raw+p blah
> # getcap blah
> blah = cap_net_admin,cap_net_raw+p
> 
> and I also tested that the 'ping' binary run as unprivileged user works
> from lustre.
> success!
> 
> 'b15587' is listed as the reason for the filtering.
> I don't know what that refers to.
> is it still relevant?
> 
> cheers,
> robin
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org