Per default dCache
xrootd is restricted to read-only,
xrootd is completely unauthenticated. A
typical error message on the clientside if the server is
read-only looks like:
xrdcp -d 1 /bin/sh root://ford.desy.de//pnfs/desy.de/data/xrd_test2Setting debug level 1 061024 18:43:05 001 Xrd: main: (C) 2004 SLAC INFN xrdcp 0.2 beta 061024 18:43:05 001 Xrd: Create: (C) 2004 SLAC INFN XrdClient kXR_ver002+kXR_asyncap 061024 18:43:05 001 Xrd: ShowUrls: The converted URLs count is 1 061024 18:43:05 001 Xrd: ShowUrls: URL n.1: root://ford.desy.de:1094//pnfs/desy.de/data/asdfas. 061024 18:43:05 001 Xrd: Open: Access to server granted. 061024 18:43:05 001 Xrd: Open: Opening the remote file /pnfs/desy.de/data/asdfas 061024 18:43:05 001 Xrd: XrdClient::TryOpen: doitparallel=1 061024 18:43:05 001 Xrd: Open: File open in progress. 061024 18:43:06 5819 Xrd: SendGenCommand: Server declared: Permission denied. Access is read only.(error code: 3003) 061024 18:43:06 001 Xrd: Close: File not opened. Error accessing path/file for root://ford//pnfs/desy.de/data/asdfas
To enable read-write access, add the following line to
.. xrootdIsReadOnly=false ..
and restart any domain(s) running a
Please note that due to the unauthenticated nature of this
access mode, files can be written and read to/from any
subdirectory in the
pnfs namespace (including the automatic
creation of parent directories). If there is no user
information at the time of request, new files/subdirectories
xrootd will inherit UID/GID from its
parent directory. The user used for this can be configured via the
To overcome the security issue of uncontrolled
xrootd read and write
access mentioned in the previous section, it is possible to
restrict read and write access on a per-directory basis (including
To activate this feature, a colon-seperated list containing
the full paths of authorized directories must be added
/etc/dcache/dcache.conf. If both read and
write access should be authorized for certain directories, add the
following line to
.. xrootdAllowedPaths=/pnfs/<example.org>/path1:/pnfs/<example.org>/path2 ..
If you want to split permissions depending on whether the operation is reading or writing, add the following lines instead:
.. xrootdAllowedReadPaths=/pnfs/<example.org>/rpath1:/pnfs/<example.org>/rpath2 xrootdAllowedWritePaths=/pnfs/<example.org>/wpath1:/pnfs/<example.org>/wpath2 ..
A restart of the
is required to make the changes
take effect. As soon as any of the above properties are set, all read or write
requests to directories not matching the allowed path lists
will be refused. Symlinks are however not restricted to these prefixes.
xrootd dCache implementation includes a generic
mechanism to plug in different authorization handlers. The only
plugin available so far implements token-based authorization
as suggested in http://people.web.psi.ch/feichtinger/doc/authz.pdf.
The first thing to do is to setup the keystore. The keystore
file basically specifies all RSA-keypairs used within the
authorization process and has exactly the same syntax as in
the native xrootd tokenauthorization implementation. In this
file, each line beginning with the keyword
KEY corresponds to a certain Virtual
Organisation (VO) and specifies the remote public (owned by
the file catalogue) and the local private key belonging to
that VO. A line containing the statement
VO:*" defines a default keypair that is used as a
fallback solution if no VO is specified in token-enhanced
xrootd requests. Lines not starting with the
KEY keyword are ignored. A template can be
The keys itself have to be converted into a certain format in order to be loaded into the authorization plugin. dCache expects both keys to be binary DER-encoded (Distinguished Encoding Rules for ASN.1). Furthermore the private key must be PKCS #8-compliant and the public key must follow the X.509-standard.
The following example demonstrates how to create and convert a keypair using OpenSSL:
Generate new RSA private key
openssl genrsa -rand 12938467 -out key.pem 1024Create certificate request
openssl req -new -inform PEM -key key.pem -outform PEM -out certreq.pemCreate certificate by self-signing certificate request
openssl x509 -days 3650 -signkey key.pem -in certreq.pem -req -out cert.pemExtract public key from certificate
openssl x509 -pubkey -in cert.pem -out pkey.pem
openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER -out <new_private_key>
openssl enc -base64 -d -in pkey.pem -out <new_public_key>
Only the last two lines are performing the actual conversion, therefore you can skip the previous lines in case you already have a keypair. Make sure that your keystore file correctly points to the converted keys.
To enable the plugin, it is necessary to add the following two lines to
/etc/dcache/dcache.conf, so that
it looks like
.. xrootdAuthzPlugin=org.dcache.xrootd.security.plugins.tokenauthz.TokenAuthorizationFactory xrootdAuthzKeystore=<Path_to_your_Keystore> ..
After doing a restart of dCache, any requests without
an appropriate token should result in an error saying
authorization check failed: No authorization token
found in open request, access denied.(error code:
If both tokenbased authorization and read-only access are activated, the read-only restriction will dominate (local settings have precedence over remote file catalogue permissions).
xrootd-implementation in dCache includes a pluggable
authentication framework. To control which authentication mechanism
is used by
xrootd, add the
option to your dCache configuration and set it to the desired value.
For instance, to enable
GSI authentication in
xrootd, add the
following line to
.. xrootdAuthNPlugin=gsi ..
GSI authentication, depending on your setup,
you may or may not want dCache to fail if the host
certificate chain can not be verified against trusted certificate
authorities. Whether dCache performs this check can be controlled
by setting the option
.. verifyHostCertificateChain=true ..
Authorization of the user information obtained
by strong authentication is performed by contacting the
service. Please refer to Chapter 11, Authorization in dCache for instructions
about how to configure
xrootd is not secure. It does not provide
confidentiality and integrity guarantees and hence does not protect
against man-in-the-middle attacks.
The previously explained methods to restrict access via
xrootd can also be used together. The precedence
applied in that case is as following:
xrootd-door can be configured to use either token authorization
or strong authentication with
A combination of both is currently not possible.
The permission check executed by the authorization plugin (if one is installed) is given the lowest priority, because it can controlled by a remote party. E.g. in the case of token based authorization, access control is determined by the file catalogue (global namespace).
The same argument holds for many strong authentication mechanisms - for
example, both the
GSI protocol as well as the
Kerberos protocols require
trust in remote authorities. However, this only affects user
authentication, while authorization decisions can
be adjusted by local site administrators by adapting the
To allow local site’s administrators to override remote
security settings, write access can be further restricted to
few directories (based on the local namespace, the
xrootd access to read-only has the highest
priority, overriding all other settings.
xrootd-door has several other configuration properties. You can configure various timeout parameters,
the thread pool sizes on pools, queue buffer sizes on pools, the
xrootd root path, the
xrootd IO queue. Full descriptions on the effect of those can be found in