Configuring XRootD Authorization¶
EL7 version compatibility
There is an incompatibility with EL7 < 7.5 due to an issue with the
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.
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 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.
/etc/xrootd/auth_file corresponds to the
acc.authdb parameter in your xrootd config.)
Here is an example
# 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
<STORAGE PATH> with the path to the directory that will contain data served by XRootD, e.g.
This path is relative to the
all.localroot configuration values, if either one is defined in the
xrootd config file.
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
|idtype||Type of id. Use
|id||Username (or groupname). Use
|path||The path prefix to be used for matching purposes.
|privs||Letter list of 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:
Follow the instructions for requesting a service certificate, using
xrootdfor both the
<OWNER>, resulting in a certificate and key in
Install and configure the LCMAPS VOMS plugin
xrootd-lcmapsand necessary configuration:
[email protected] # yum install xrootd-lcmaps vo-client
Configure access rights for mapped users by creating and modifying the XRootD authorization file
Modify your XRootD configuration:
Choose the configuration file to edit based on the following table:
If you are running XRootD in... Then modify the following file... Standalone mode
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
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,
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:
On the XRootD host, add your DN to /etc/grid-security/grid-mapfile
Add a line to
/etc/xrootd/auth_fileto ensure the mapped user can write to
Restart the xrootd service. (See this section for more information of managing XRootD services.)
Generate your proxy and verify that you can successfully transfer files:
[email protected]ient $ 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 2for more information.