gPlazma policy file contains two lines for this
# Built-in gPLAZMAlite grid VO role mapping gridVoRolemapPath="/etc/grid-security/grid-vorolemap" gridVoRoleStorageAuthzPath="/etc/grid-security/storage-authzdb"
The second is the storage-authz-db used in other plugins. See the above documentation Configuring storage-authzdb for how to create the file.
The file is similar in format to the grid-mapfile, however there is an additional field following the DN (Certificate Subject), containing the FQAN (Fully Qualified Attribute Name).
"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms" uscms01 "/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsprod" cmsprod
Therefore each line has three fields: the user’s DN, the user’s FQAN, and the username that the DN and FQAN combination are to be mapped to.
The FQAN is sometimes semantically referred to as the “role”. The same user can be mapped to different usernames depending on what their role is. The role is determined by how the user creates their proxy, for example, using voms-proxy-init. The FQAN contains the user’s Group, Role (optional), and Capability (optional). The latter two may be set to the string “NULL”, in which case they will be ignored by the plugin.
If a user is authorized in multiple roles, for example
"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms" uscms01 "/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsuser" cms2847 "/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsphedex" phedex "/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsprod" cmsprod
they would be mapped to the username corresponding to the role found in the proxy that the user creates for use by the client software. Starting in dCache 1.8, if the user actually creates several roles in their proxy, authorization (and subsequent check of path and filesystem permissions) will be attempted for each role in the order that they are found in the proxy. In a griftp URL, the user may also explicity request a username
in which case other roles will be disregarded.
Instead of individual DNs, it is allowable to use
"*" as the first
field, such as
"*" "/cms/uscms/Role=cmsprod" cmsprod
In that case, any DN with the corresponding role will
match. It should be noted that a match is first attempted with
the explicit DN. Therefore if both DN and
"*" matches can be made, the DN match will
take precedence. This is true for the revocation matches as
well (see below).
Thus a user with subject
"/DC=org/DC=doegrids/OU=People/CN=Ted Hesselroth 897321"
will be mapped to username
cmsprod via the
above storage-authzdb line with
"*" for the
DN, except if there is also a line such as
"/DC=org/DC=doegrids/OU=People/CN=Ted Hesselroth 898521" "/cms/uscms/Role=cmsprod" uscms01
in which case the username will be
To create a revocation entry, add a line with
- as the username, such as
"/DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov 623542" "/uscms/production" -
or modify the username of the entry if it already exists. The behaviour is undefined if there are two entries which differ only by username.
Since DN is matched first, if a user would be authorized by
his VO membership through a
"*" entry, but
is matched according to his DN to a revocation entry,
authorization would be denied. Likewise if a whole VO were
denied in a revocation entry, but some user in that VO could
be mapped to a username through his DN, then authorization
would be granted.
Suppose that there are users in production roles that are
expected to write into the storage system data which will be
read by other users. In that case, to protect the data the
non-production users would be given read-only access. Here in
production role maps to username
and the role which reads the data maps to
"*" "/cms/uscms/Role=cmsprod" cmsprod "*" "/cms/uscms/Role=cmsuser" cmsuser
The read-write privilege is controlled by the third field in
the lines of
authorize cmsprod read-write 9811 5063 / /pnfs/fnal.gov/data / authorize cmsuser read-only 10001 6800 / /pnfs/fnal.gov/data /
Another use case is when users are to have their own
directories within the storage system. This can be arranged
gPlazma configuration files by mapping each
user’s DN to a unique username and then mapping each username
to a unique root path. As an example, lines from
therefore be written
"/DC=org/DC=doegrids/OU=People/CN=Selby Booth" "/cms" cms821 "/DC=org/DC=doegrids/OU=People/CN=Kenja Kassi" "/cms" cms822 "/DC=org/DC=doegrids/OU=People/CN=Ameil Fauss" "/cms" cms823
and the corresponding lines from
/etc/grid-security/storage-authzdb would be
authorize cms821 read-write 10821 7000 / /pnfs/fnal.gov/data/cms821 / authorize cms822 read-write 10822 7000 / /pnfs/fnal.gov/data/cms822 / authorize cms823 read-write 10823 7000 / /pnfs/fnal.gov/data/cms823 /
Starting with dCache 1.8, regular expressions are supported
file. Substitutions by regular expression group are also
permitted. Place a regular expression in the username field of
storage-authzdb file. Any groups in
the regular expression (defined by enclosure in parentheses)
can be referred to in later fields of the line, and the
corresponding susbstitution will be made when the file is
read. For example, the above lines for granting users
individual directories can be replaced with
authorize cms(\d\d\d) read-write 10$1 7000 / /pnfs/fnal.gov/data/cms$1 /
in which case
cms(\d\d\d) and the group
(\d\d\d) is substituted in
10$1 to yield
/pnfs/fnal.gov/data/cms$1 to yield
/pnfs/fnal.gov/data/cms821, and so on.