Optimizing Resource Access: Implementing 'sss' Security for XrootdFS on User Nodes

[ickc]

We aim to enhance the user experience by mounting the grid storage system (located at root://bohr3226.tier2.hep.manchester.ac.uk:1094/dpm/tier2.hep.manchester.ac.uk/home/souk.ac.uk/) on nodes accessible to our users.

According to the xrootdfs man page, employing an 'sss' security node could be a viable solution:

SECURITY
       By default, XrootdFS does not send individual user identity to the Xrootd storage servers.  So Xrootd storage thinks that all operations from an XrootdFS instance come
       from the user that runs the XrootdFS instance. When the Xrootd "sss" security module (Simple Shared Security) is enabled at both XrootdFS and Xrootd storage system,
       XrootdFS will send individual user identity information to the Xrootd storage servers. This info can be used along with the Xrootd ACL to control file/directory access.

       To use "sss" security module, both Xrootd data servers and XrootdFS should be configured to use "sss" in a particular way, e.g. both sides should use a key file that con‐
       tains the same key generated by the xrdsssadmin program in the following way:

       xrdsssadmin -k my_key_name -u anybody -g usrgroup add keyfile

       (change only "my_key_name" and "keyfile"). Please refer to environment variable "XrdSecsssKT" in Xrootd "Authentication & Access Control Configuration Reference" for more
       information on the location of the keyfile and its unix permission bits. That same document also describes the Xrootd ACL DB file.

       To enable "sss" with XrootdFS, use the sss=/keyfile option with XrootdFS.

       The following example shows how to use both unix and sss security modules with the Xrootd data servers.

                xrootd.seclib /usr/lib64/libXrdSec.so
                sec.protocol /usr/lib64 sss -s /keyfile
                sec.protocol /usr/lib64 unix
                acc.authdb /your_xrootd_ACL_auth_db_file
                acc.authrefresh 300
                ofs.authorize

@rwf14f, @afortiorama, could you please confirm if a similar setup is in operation at Blackett, and if so, what steps are necessary for us to replicate this configuration? Thank you.

[rwf14f]

No there isn't. I've only suggested to use xrootdfs for Librarian because it appears to be the only available method to get the data transfers working without major development work. I don't think this has been tested yet, so I have no idea how the performance looks like. Our xrootd servers use gsi (ie certificate proxies) for authentication which I've also used on the librarian server. This is supposed to be an interim solution until we get Ceph into production. Once it is, we can mount the Ceph volumes on the cluster nodes, as well as on the Librarian server and both, Librarian and the users can access the cephfs filesystem directly.

[ickc]

So it seems there's a discussion on xrootdfs and librarian somewhere. Is the use of librarian related to us (SO:UK Data Centre)?

I was trying to mount the grid storage system through xrootdfs and davfs without success. The xrootdfs process would exit 0, but the directory is empty. Have you tried mounting them and can you share instructions?

We are not looking for performance when mounting at this point, but more focusing on the user experience in interacting with the data.

[rwf14f]

You should stop trying to do this because it's going to cause more problems than it solves. If you want to make accessing the storage easier for users then you can provide some basic scripts that hide some of it.

davs

davfs won't work at all because it was designed to work with standard single webdav servers, not with Grid ones. Afaik, it only supports user/password authentication, not the GSI authentication that is required by our storage.

xrootdfs

• xrootdfs supports GSI authentication, you need to have a valid VOMS proxy to access / mount the storage.
• The storage is accessed using the credentials of the user that mounted it.
• The users would have to mount it themselves using their own VOMS proxies.
• All I/O to the mounted file system is done with the credentials and permissions of the user who mounted it.
• The mount point is world readable and world writeable by default, any user with access to the system has full access to the mount point. This access is only limited by the credentials of the user who mounted it.
• When the VOMS proxy expires you loose access to the mount point and have to umount and remount it.

Yes, the Librarian work is related to SO:UK. Hasib and I are looking into it. xrootdfs is an option there because the Librarian server is a restricted system with limited access which mitigates the security implications that xrootdfs has when used on a shared system.

[ickc]

@rwf14f, for davfs, there seems a way to authorized using GSI, but it fails silently.

For xrootdfs, I already knew everything you said above, as I intended to provide user instructions to mount them themselves. Again, this is for user experience to interact with the grid storage system. The POSIX filesystem is the best way to wrap around that abstraction. For example, if someone want to run ranger or tree or whatever to see what's inside, these tools expects POSIX filesystem and I can't possibly write wrappers or contributes to all those tools. The least the users need to adapt their workflow to our system, the better.

For this alone (mounting via their own user certificates by following provided instructions), it is not the point of this issue. This issue is about setting up sss which exactly is trying to deal with the security implications you're alluding to:

When the Xrootd "sss" security module (Simple Shared Security) is enabled at both XrootdFS and Xrootd storage system, XrootdFS will send individual user identity information to the Xrootd storage servers. This info can be used along with the Xrootd ACL to control file/directory access.

If there's security risk from Xrootd, it should be raise there. But as long as there's no security risk in their tool, we plan to use all the features available to provide the best possible user experience with as few unnecessary constraints as possible.

Also ping @shaikhhasib as it seems you're working on this too. Do you have chance to get it (mounting using user certificates) working?

[ickc]

c.f. https://github.com/xrootd/xrootd/issues/1219

[ickc]

@shaikhhasib, @DanielBThomas,

A script to use xrootdfs is provided for end users to mount the grid storage system in their home. See commit 0a5e9fcab90d5b2dbb1abcec8ab5f069387240ee.

Since Xrootd "sss" security module (Simple Shared Security) requires coordinations with the xrootd server, and from the above response it seems they are not enthusiastic in supporting it. And since it will soon be transitioning into CephFS making this obsolete, therefore we will stop at here and let users mounting it themselves.

Documentation will follows very soon.

[ickc]

Correction: davfs doesn't seem to support GSI authentication.

Documentation to mount xrootdfs is added in commit 0c23876 6e6c6e6, which is now live in 1.3.4.2.7. Mounting the grid storage system as a POSIX filesystem - SO:UK Data Centre 0.1.2 documentation.