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.
The XRootD LCMAPS authorization method depends on configuring LCMAPS with the VOMS plugin. LCMAPS maps an incoming user's grid credentials to a Unix account name; the permissions listed in the authorization file all reference Unix account names.
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. If this behaviour is not desired, enable
XRootD multi-user support.
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 * <STORAGE PATH>/private -rl <STORAGE PATH> 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:
-
Install CA certificates and manage CRLs
-
Copy your host certificate and key to
/etc/grid-security/xrd/xrdcert.pem
and/etc/grid-security/xrd/xrdkey.pem
, respectively. -
Install and configure the LCMAPS VOMS plugin
-
Install
xrootd-lcmaps
and necessary configuration:[email protected] # yum install xrootd-lcmaps vo-client
-
Configure access rights for mapped users by creating and modifying the XRootD authorization file
-
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:
-
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
-
On the XRootD host, add your DN to /etc/grid-security/grid-mapfile
-
Add a line to
/etc/xrootd/auth_file
to ensure the mapped user can write to<DESTINATION PATH>
-
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] $ 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.