

Configuring XRootD Authorization

EL7 version compatibility

There is an incompatibility with EL7 < 7.5 due to an issue with the globus-gsi-proxy-core package

There are several authorization options in XRootD available through its security plugins. In this document, we will cover the xrootd-lcmaps security option supported in the OSG.

Note

On the data nodes, the files will actually be owned by unix user xrootd (or other daemon user), not as the user authenticated to, under most circumstances. XRootD will verify the permissions and authorization based on the user that the security plugin authenticates you to, but, internally, the data node files will be owned by the xrootd user.

Authorization file

XRootD allows configuring fine-grained file access permissions based on usernames and paths. This is configured in the authorization file /etc/xrootd/auth_file on the data server node, which should be writable only by the xrootd user, optionally readable by others.

(The path /etc/xrootd/auth_file corresponds to the acc.authdb parameter in your xrootd config.)

Here is an example /etc/xrootd/auth_file :

# This means that all the users have read access to the datasets, _except_ under /private
u * -rl <STORAGE PATH>/private /data/xrootdfs rl

# Or the following, without a restricted /private dir
# u * <STORAGE PATH> rl

# This means that all the users have full access to their private home dirs
u = <STORAGE PATH>/home/@=/ a

# This means that the privileged 'xrootd' user can do everything
# There must be at least one such user in order to create the
# private dirs for users willing to store their data in the facility
u xrootd <STORAGE PATH> a

# This means that users in group 'biology' can do anything under the 'genomics' directory
g biology <STORAGE PATH>/genomics a

Replacing <STORAGE PATH> with the path to the directory that will contain data served by XRootD, e.g. /data/xrootdfs. This path is relative to the oss.localroot or all.localroot configuration values, if either one is defined in the xrootd config file.

Note

Specific paths need to be specified before generic paths; e.g., this does not work:

    u * rl /data/xrootdfs -rl /data/xrootdfs/private

More generally, each configuration line of the auth file has the following form:

idtype id path privs

Field	Description
idtype	Type of id. Use u for username, g for group, etc.
id	Username (or groupname). Use * for all users or = for user-specific capabilities, like home directories
path	The path prefix to be used for matching purposes. @= expands to the current user name before a path prefix match is attempted
privs	Letter list of privileges: a - all ; l - lookup ; d - delete ; n - rename ; i - insert ; r - read ; k - lock (not used) ; w - write ; - - prefix to remove specified privileges

For more details or examples on how to use templated user options, see XRootd Authorization Database File.

Ensure the auth file is owned by xrootd (if you have created file as root), and that it is not writable by others.

[email protected] # chown xrootd:xrootd /etc/xrootd/auth_file
[email protected] # chmod 0640 /etc/xrootd/auth_file  # or 0644

Enabling xrootd-lcmaps authorization

The xrootd-lcmaps security plugin uses the lcmaps library and the LCMAPS VOMS plugin to authenticate and authorize users based on X509 certificates and VOMS attributes. Perform the following instructions on all data nodes:

1. Install CA certificates and manage CRLs

2. Follow the instructions for requesting a service certificate, using xrootd for both the <SERVICE> and <OWNER>, resulting in a certificate and key in /etc/grid-security/xrd/xrdcert.pem and /etc/grid-security/xrd/xrdkey.pem, respectively.

3. Install and configure the LCMAPS VOMS plugin

4. Install xrootd-lcmaps and necessary configuration:

   [email protected] # yum install xrootd-lcmaps vo-client
   

5. Configure access rights for mapped users by creating and modifying the XRootD authorization file

6. Modify your XRootD configuration:

   1. Choose the configuration file to edit based on the following table:

      If you are running XRootD in...	Then modify the following file...
      Standalone mode	/etc/xrootd/xrootd-standalone.cfg
      Clustered mode	/etc/xrootd/xrootd-clustered.cfg

   2. Add the following lines to the configuration that you chose above:

      xrootd.seclib /usr/lib64/libXrdSec-4.so
      sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates \
                          -cert:/etc/grid-security/xrd/xrdcert.pem \
                          -key:/etc/grid-security/xrd/xrdkey.pem \
                          -crl:1 \
                          -authzfun:libXrdLcmaps.so \
                          -authzfunparms:lcmapscfg=/etc/lcmaps.db,loglevel=0,policy=authorize_only \
                          -gmapopt:10 -gmapto:0
      acc.authdb /etc/xrootd/auth_file
      ofs.authorize
      

7. Restart the relevant services

Verifying XRootD Authorization

To verify the LCMAPS security, run the following commands from a machine with your user certificate/key pair, xrootd-client, and voms-clients-cpp installed:

1. Destroy any pre-existing proxies and attempt a copy to a directory (which we will refer to as <DESTINATION PATH>) on the <XROOTD HOST> to verify failure:

   [email protected] $ voms-proxy-destroy
   [email protected] $ xrdcp /bin/bash root://<XROOTD HOST>/<DESTINATION PATH>
   180213 13:56:49 396570 cryptossl_X509CreateProxy: EEC certificate has expired
   [0B/0B][100%][==================================================][0B/s]
   Run: [FATAL] Auth failed
   

2. On the XRootD host, add your DN to /etc/grid-security/grid-mapfile

3. Add a line to /etc/xrootd/auth_file to ensure the mapped user can write to <DESTINATION PATH>

4. Restart the xrootd service. (See this section for more information of managing XRootD services.)

5. Generate your proxy and verify that you can successfully transfer files:

   [email protected] $ voms-proxy-init
   [email protected] $ xrdcp  /bin/sh root://<XROOTD HOST>/<DESTINATION PATH>
   [938.1kB/938.1kB][100%][==================================================][938.1kB/s]
   

   If your transfer does not succeed, run the previous command with --debug 2 for more information.