6th dCache Workshop - Access Control

Aus Gkswiki

This article is a short hands-on for how to configure your dCache setup (which is assumed to be the same as if you would have completed the installation guide) so you may successfully perform authentificated transfers.

Configure dCache

1. Let dCache run a SRM and gPlazma service.

   vi /etc/dcache/layouts/mylayout.conf

   (…)
   [srmDomain]
   [srmDomain/srm]
   [srmDomain/gplazma]
   [srmDomain/spacemanager]
   (…)

   SRM will be used as access point for our transfers. It will negotiate the user authentification with gPlazma, the authorisation with Chimera and the data transfer with the GridFTP door.
2. Edit dcachesrm-gplazma.policy.

   vi /etc/dcache/dcachesrm-gplazma.policy

   (…)
   # Switches
   xacml-vo-mapping="OFF"
   saml-vo-mapping="OFF"
   # kpwd="ON"
   kpwd="OFF"
   grid-mapfile="OFF"
   # gplazmalite-vorole-mapping="OFF"
   gplazmalite-vorole-mapping="ON"
   (…)

   We disabled the kpwd-Plugin and enabled gplazma-vorole-mapping. Since the latter one is the only used plugin with this configuration, we do not have to change the prioritisation.
3. Edit grid-vorolemap.

   vi /etc/grid-security/grid-vorolemap

   "*" "/desy" desy001
   "*" "/desy/workshop" desy002
   
   "/C=DE/ST=Hamburg/O=dCache.ORG/CN=Bernd das Brot" "" -

   This is a minimalistic mapping table for gPlazma which enforces the following rules (There are a couple of implicit rules active, which will be demonstrated and explained later.):
   1. Every user with the VOMS role '/desy' is regarded to as (virtual) user "desy001".
   2. Likewise for the VOMS role '/desy/woekshop' and user "desy002".
   3. The user with DN "/C=DE/ST=Hamburg/O=dCache.ORG/CN=Bernd das Brot" is banned from our dCache, no matter which VOMS role he may use.
4. Edit storage-authzdb.

   vi /etc/grid-security/storage-authzdb

   version 2.1
   
   authorize desy001 read-write 55001 55001 / / /
   authorize desy002 read-write 55002 55002 / / /

   With this settings, we have two different uids and gids assigned to the users "desy001" and "desy002".
5. Start the srmDomain.

   dcache start srmDomain

6. Prepare some directories for our tests.

   mkdir -p /pnfs/dcache.org/data/desy/workshop
   chimera-cli chown /pnfs/dcache.org/data/desy 55001
   chimera-cli chown /pnfs/dcache.org/data/desy/workshop/ 55002

7. Unfortunately, ls does not show you the correct uid and gid of files and directories, since we do not have the service "idmapper" running. Compare the output of the folowing commands.

   ls -Rn /pnfs/dcache.org/data/desy
   chimera-cli ls /pnfs/dcache.org/data/desy

Perform tests

All these tests should be carried out as regular user and not with root privileges!

1. Generate grid proxy, which are required to identify yourself to dCache, if you want to use secured transfer protocols.

   voms-proxy-init -key $HOME/.globus/Kermit-key.pem -cert $HOME/.globus/Kermit-cert.pem

2. You can review the proxy attributes anytime.

   voms-proxy-info -all

3. Try to write a file. Failure is to be expected, because your current proxy does not include any VOMS role. This case is not covered by our configuration for gPlazma, hence there is no valid mapping for you.

   srmcp file:////bin/bash srm://$(hostname -f)/pnfs/dcache.org/data/desy/srmcp.1

4. Change your proxy – note the different output from voms-proxy-info – and try again.

   voms-proxy-info -all
   voms-proxy-init -key $HOME/.globus/Kermit-key.pem -cert $HOME/.globus/Kermit-cert.pem -voms desy:/desy
   srmcp file:////bin/bash srm://$(hostname -f)/pnfs/dcache.org/data/desy/srmcp.2

5. Change your proxy (again, review your proxy with voms-proxy-info) and try again. This attempt will fail, because you get uid and gid that differ from those known to be the owner of /pnfs/dcache.org/data/desy.

   voms-proxy-init -key $HOME/.globus/Kermit-key.pem -cert $HOME/.globus/Kermit-cert.pem -voms desy:/desy/workshop
   srmcp file:////bin/bash srm://$(hostname -f)/pnfs/dcache.org/data/desy/srmcp.3

6. Change your proxy and try again.

   voms-proxy-init -key $HOME/.globus/Kermit-key.pem -cert $HOME/.globus/Kermit-cert.pem -voms desy:/desy/workshop
   srmcp file:////bin/bash srm://$(hostname -f)/pnfs/dcache.org/data/desy/workshop/srmcp.4

7. Try reading a file.

   srmcp srm://$(hostname -f)/pnfs/dcache.org/data/desy/srmcp.2 file:////dev/null

8. How about Bernd? You will see, that he is not allowed to do anything, although his FQANs are chosen correctly. That is, because we banned him completely.

   voms-proxy-init -key $HOME/.globus/Bernd-key.pem -cert $HOME/.globus/Bernd-cert.pem -voms desy:/desy
   srmcp file:////bin/bash srm://$(hostname -f)/pnfs/dcache.org/data/desy/srmcp.5
   srmcp srm://$(hostname -f)/pnfs/dcache.org/data/desy/srmcp.2 file:////dev/null

Back to the timetable.