Scalla: Extended Features Supplement
Authentication & Access Control
Configuration Reference
Andrew Hanushevsky, SLAC
Gerardo Ganis, CERN
10-January-2007
Scalla: Structured Cluster Architecture for Low Latency Access
©2005-2007 by the Board of Trustees of the Leland Stanford, Jr., University
All Rights Reserved
Produced under contract DE-AC03-76-SFO0515 with the Department of Energy
This code is available under a BSD-style license allowing minimally restricted use.
1.1 Client/Server Authentication
2 Specifying Conditional Directives
3 Authentication Configuration
3.2.2.1 Configuring GSI Security
3.2.3.1 Configuring Kerberos IV Security
3.2.4.1 Configuring Kerberos V Security
3.2.5.1 Configuring pwd Security
4 Default Authorization Configuration
5.1 Default Authorization Database Record
This document describes the configuration of the security and the default access control components of the extended root daemon (xrootd). The xrootd consists of eight configurable components (un-shaded components are documented in this reference):
|
Component |
Purpose |
|
sec |
Security authentication |
|
acc |
Access control (i.e., authorization) |
|
ofs |
Open file system coordinating acc, odc, & oss components |
|
oss |
Open storage system (i.e., file system implementation) |
|
odc |
Open distributed clustering |
|
olb |
Open load balancing |
|
xrd |
Extended request daemon. |
|
xrootd |
xrootd protocol. |
Configuration directives for each component come from a configuration file. The xrootd structure forces that all components read their directives from the same configuration file. This is the configuration file specified when xrootd was started (see the –c option xrootd option). This is possible because each component is identified by a unique 3-letter prefix. This prefix is used to qualify each directive so that components can restrict themselves to relevant directives. Each unique prefixes is identical to the three-letter component name as shown in the previous table (e.g., sec).
Configuration file lines that do not start with a recognized identifier are ignored. This includes blank record and comment lines (i.e., lines starting with a pound sign, #).
By default, security and access control features are disabled. These features can be enabled with the following xrootd and ofs directives:
|
Directive |
Purpose |
|
xrootd.fslib |
Load the shared library implementing the ofs, oss, odc, and acc components. |
|
xrootd.seclib |
Load the shared library implementing the sec (authentication) component. |
|
ofs.authlib |
Load the shared library implementing the acc (authorization and access control) component. |
|
ofs.authorize |
Enables access control, acc component. |
This document only describes how to configure the sec, and acc components. These two components are normally configured together independent of any other components.
The authentication component is structured as a highly versatile multi-protocol suite. In order to accomplish this task, it is organized into a set of shared libraries:
|
Shared Library |
Purpose |
|
libXrdSec.so |
Protocol manager and host-based authentication. |
|
libXrdSecgsi.so |
Dynamically loadable GSI authentication. |
|
libXrdSeckrb4.so |
Dynamically loadable Kerberos IV authentication. |
|
libXrdSeckrb5.so |
Dynamically loadable Kerberos V authentication. |
|
libXrdSecpwd.so |
Dynamically loadable password-based authentication. |
|
LibXrdSecxxxx.so |
Dynamically loadable xxxx authentication protocol. |
This means that libXrdSec.so must be available since it is needed to boot-strap additional protocols. For each requested protocol (e.g., krb5), its corresponding shared library must be available.
For servers, the location of libXrdSec.so is specified using the xroot seclib directive (see the “xrd & xrootd Configuration Guide”). Additional libraries are specified using the sec.protocol directive documented in this guide.
For clients, the task of deploying shared libraries is more problematic because library placement and location is not immediately obvious. The same rules apply; libXrdSec.so and any additional protocol libraries must be available. Typically, these libraries should be placed in one of the directories listed in the client’s LD_LIBRARY_PATH environmental variable. Alternatively, they can be placed in a well-known linker/loader location (e.g., /usr/local/lib).
The client will load libraries, as available, compatible with the security configuration defined for the server. Thus, the server controls what protocols the client will use, if any. While this potentially simplifies security administration, it does complicate the client-side environment. This is because the client may be potentially running multiple protocols at the same time, depending on what set of servers the client wants to use. Generally, however, this is transparent to the client application.
The default authorization component is already built into xrootd and needs only to be activated using the ofs.authorize directive. If you use the default authorization scheme, you must also create an authorization file that lists client capabilities. The file is specified by the acc.authdb directive, Procedures must be developed to properly share this file with all of the servers that rely on it to provide cohesive access control. Fortunately, authorization is only a server-side issue.
Other authorization schemes may be used with xrootd. A specific scheme is implemented as a plug-in. The shared library containing the implementation is then specified using the ofs.authlib directive.
In a clustered environment, authorization should be enabled on all actual data servers since clients might bypass a redirector and communicate directly with a data server. Consider enabling authorization at the redirector level only if you need to control file requests. Since a request for a file does not implicitly allow actual access to file data; authorization at the redirector level generally does not enhance security but may add significant overhead.
The if-fi directives are used to allow you to optionally include directives based on host and instance name. The syntax for this directive pair is:
if [ hostpat [. . .] ] [ conds ]
[ other directives when if is true ]
[ else
[ other directives when if is false ]
]
fi
hostpat: host | host+ | pfx* | *sfx | pfx*sfx]
conds: cond1 | cond2
cond1: exec pgm [. . .] [&& cond2]
cond2: named name [. . .]
Function
Specify the conditions under which subsequent directives are to be used.
Parameters
hostpat
is the pattern of the host to which subsequent directive applies. All non-applicable hosts ignore all directives until the fi. Host patterns are:
host Any host that matches the specified DNS name.
host+ Any host that has an address that matches any of the addresses assigned to host.
pfx* Any host starting with pfx.
*sfx Any host ending with sfx.
pfx*sfx Any host beginning with pfx and ending with sfx.
name
is an instance name (i.e., a name that can be specified using the –n command line option). All directives until the fi are ignored unless the olbd has been given one of the names in the list of names,
pgm
is the prefix-name of the executable. The prefix-name is defined to be all of the characters in the base filename (i.e., the directory path removed) up to but not including the first dot in the name, if any. If the name starts with a dot, the prefix-name is the complete base filename.
Defaults
None. At least one hostpat, exec or the named keyword must be specified.
Notes
1) All specified conditions must be true (i.e., hostpat, exec, and named) for the subsequent directives to be used.
2) Every if must be followed by a fi. Every fi must be preceded by an if.
3) Every else must be preceded by an if.
4) Nested if directives are not allowed.
5) The name anon refers to servers that were not given a name via –n.
Examples
if *slac.stanford.edu named anon
acc.authdb /opt/xrd/etc/Authfile
fi
if named public
acc.audit deny grant
fi
if exec xrootd && named public
acc.audit deny grant
else
acc.audit deny
fi
sec.protbind hostpat { none | [ only ] protocols }
hostpat: prefix[*][suffix] | [prefix][*]suffix
Function
To bind a set of protocols to one or more hosts.
Parameters
hostpat
is the hostname pattern to be used for matching host names. A pattern is a standard DNS name with an optional single asterisk somewhere in the specification. All of the characters prior to the asterisk (i.e., prefix) must match the left-most characters of the host name and all of the characters after the asterisk (i.e., suffix) must match the right-most characters of the host name. If the hostpat does not contain an asterisk, the all of the characters must match.
none
indicates that incoming clients from hosts matching hostpat need not supply any credentials.
only
indicates that incoming clients from hosts matching hostpat must supply credentials using one of the protocols that follow.
protocols
are one or more blank-separated protocol ids that are to be bound to the host. Each protocol id must have been previously defined with the protocol directive.
Defaults
All of the defined protocols are presented to each connecting client as acceptable authentication protocols. See the notes on how to change the default.
Notes
1) The protbind directive allows you to determine which authentication protocols are valid from which host. Alternatively, the protbind directive can be used to lessen authentication requirements from certain hosts (e.g., those behind a firewall vs. the ones outside a firewall).
2) Incoming clients from hosts bound to none are not asked to supply credentials.
3) Order is important. Host matching occurs in reverse order of specification. Specify the most general hostpat first and the least general, last.
4) If the hostpat is a single asterisk, then this defines the actual default for all unbound hosts.
5) The protbind directive is meant to lessen the security requirements on certain hosts. Unless only is specified, it does not restrict a host from using any defined security protocol, even if that protocol is not presented to the host as an option.
6) Because host protocol is the least restrictive authentication mechanism, binding the built-in host protocol to a host makes any other bindings to the host superfluous.
Example
sec.protbind bronco*slac.stanford.edu host
sec.protocol [ libpath ] protid [ parms ]
Function
Define the characteristics of an authentication protocol.
Parameters
libpath
is the absolute path where the protocol shared library exists. If an absolute path is not specified, the library must be on the search path defined by the LD_LIBRARY_PATH environmental variable.
protid
is the unique 1- to 7-character protocol identifier.
parms
are the parameters required by the protocol to operate successfully. The parameters are protocol dependent. The note and subsequent sections describe the parameters needed for various protocols. The parms can also be specified with the protparm directive.
Defaults
There are no defaults. Each protocol must be appropriately defined in order for it to be used.
Notes
1) Each supported protocol has a 1- to 4-characterunique identifier, the protid. The sec component currently comes with support for three protocols:
o host authenticates a user by originating host name only,
o gsi authenticates a user using GSI protocol,
o krb4 authenticates a user using Kerberos IV protocol,
o krb5 authenticates a user using Kerberos V protocol, and
o pwd authenticates a user using a password-based protocol.
Other protocols may be supported by an installation. Refer to the “xrootd Developer’s Reference” on how to add new protocol support.
2) Even though the host protocol is built-in, it will not be used unless specified with a protocol directive.
3) Because host protocol is the least restrictive authentication mechanism; allowing its unbound use (see the protbind directive) makes all other protocols superfluous. A warning message is issued if you define the host protocol but do not restrict its use to certain hosts.
4) The following sections describe the required parameters, parms, for each protocol requiring configuration (host protocol does not need any parameters).
Example
sec.protocol host
sec.protocol host
Function
Enable host protocol to be used.
Defaults
Even though the host protocol is built-in; it will not be used unless specified with a protocol directive.
Notes
1) Because host protocol is the least restrictive authentication mechanism; allowing its unbound use (see the protbind directive) makes all other protocols superfluous. A warning message is issued if you define the host protocol but do not restrict its use to certain hosts.
Example
sec.protocol host
sec.protocol [ libpath ] gsi [-d:level] [-certdir:dir]
[-cert:file] [-key:file] [-crl:option]
[-crldir:dir] [-crlext:extension]
[-cipher:ciphers] [-md:mds]
Function
Define the characteristics of the gsi authentication protocol.
Parameters
libpath
is the absolute path where the protocol shared library exists. If an absolute path is not specified, the library must be on the search path defined by the LD_LIBRARY_PATH environmental variable.
d:level
sets the verbosity level for this module to level; the level can be set to 1 (low), 2 (medium) or 3 (high or dump). Invoking xrootd with the verbose option –d sets the internal verbosity for this module to 1. Default is 0.
certdir:dir
specifies an alternative directory path for trusted Certificate Authority certificates; the path indicated by dir can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME.
Default is /etc/grid-security/certificates .
cert:file
specifies an alternative path for the file containing the certificate to be used by the server; the path leading to file can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME.
Default is /etc/grid-security/xrd/xrdcert.pem .
key:file
specifies an alternative path for the file containing the private key associated with the server certificate (server must have read access to the file) ; the path leading to file can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME.
Default is /etc/grid-security/xrd/xrdkey.pem .
crl:option
defines the type of check to be performed on CRLs:
0 do not care; ignore any CRL information for the CA being used for certificate chain verification;
1 use CRL if available; if the CRL certificate is missing for a given CA, the related CRL is assumed to be empty;
2 require CRL for any trusted CA, but do not stop if the CRL certificate is not up-to-date;
3 require an up-to-date CRL for each CA .
Default is 1.
crldir:dir
specifies an alternative directory path for CRL certificates; the path indicated by dir can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME. By the default CRLs are searched for in the same path as for CA certificates.
crlext:extension
specifies an alternative default extension for CRL files. Default is “.r0”.
cipher:ciphers
specifies a colon-separated list of ciphers to be used for the session symmetric key. Default is “aes-128-cbc:bf-cbc:des-ede3-cbc” (OpenSSL naming convention).
md:mds
specifies a colon-separated list of message digests to be used for integrity checks and signatures. Default is “sha1:md5” (OpenSSL naming convention).
Defaults
See description of each single parameter.
Notes
1) Servers usually use a dedicated service-certificate whose CN is of the form
CN = service/Fully.Qualified.Hostname
e.g. CN =
xrd/pcepsft43.cern.ch
To make servers to use standard user certificates
specify the
coordinates of the certificate and its key with the cert and key
keywords above. In such a case, the pass-phrase for the private key will
be prompted for at server start-up .
2) The possibility to specify the extension for CRL certificate files is provided to speed-up loading of certificates; if the extension or the corresponding file are missing, the whole set of files in the directory is tested and the relevant file eventually found if present.
Example
sec.protocol gsi –crl:3
Follow these steps to configure GSI protocol for xrootd:
1. Locate
a valid certificate to be used by the server. This may be a service certificates
have the Common Name CN in the form
CN = service/Fully.Qualified.Hostname
and private key files protected only by the file system permissions (typical
permission mask is 0400). The CN is the final part of the subject name which
can be displayed using, for example, the command
openssl x509 –in Certificate.pem -subject
(use ‘-text’ in place of ‘-subject’ to display the full
certificate content).
Hosts have usually service certificates with CN of the type host/hostname.dom.ain
; however, the associated private key files typically require root privileges to be read. If a valid
certificate cannot be located, follow CA specific instructions for submission
of a certificate request.
2. Locate the directory path with the certificates for the trusted CAs. The name of files with CA certificates are of the type <subject_hash>.0; for example, for the CERN CA, the certificate file is fa3af1d7.0 .
3. If strong requirements about the CRLs have to be applied, locate the CRL certificate files; these are usually located in the same directory as the CA certificates, have the same name but extension “.r0”; for the example above, the CRL file is fa3af1d7.r0 .
4. If some non-default values are found at points 1-3, add the relevant parameters in the sec.protocol directive of the configuration file.
The default settings should be adequate for most of the use cases. Exceptions to the rule may be the location of the CA certificates and related CRLs, and the strength of the requirement about CRLs.
The following environment variables are provided to change the defaults on the client side:
XrdSecDEBUG verbose level; the level can be set to 1 (low), 2 (medium) or 3 (high or dump). Default is 0.
XrdSecGSIUSERCERT alternative full path to the file containing the certificate to be used by the client; the path can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME. Default is $HOME/.globus/usercert.pem .
XrdSecGSIUSERKEY alternative full path to the file containing the private key associated with client certificate; the path can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME. Default is $HOME/.globus/userkey.pem .
XrdSecGSIUSERPROXY alternative full path to the file containing the user proxy certificate to be used by the client; the path can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME. Default is /tmp/x509up_uuid.
XrdSecGSIPROXYVALID validity of the proxy certificate; formst is in the form “hh:mm”. Default is “12:00”, i.e. 12 hours.
XrdSecGSIPROXYKEYBITS bit strength of the proxy PKI. Default is 512 .
XrdSecGSIPROXYDEPLEN number of children generations which can originate from this proxy. Controls delegation. Use -1 for infinite. Default is 0.
XrdSecGSICERTDIR alternative full path to the directory containing the CA certificates; the path can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME. Default is /etc/grid-security/certificates .
XrdSecGSICHECKCRL type of check to be performed on CRLs:
0 do not care; ignore any CRL information for the CA being used for certificate chain verification;
1 use CRL if available (if the CRL certificate is missing for a given CA, the related CRL is assumed to be empty);
2 require CRL for any trusted CA, but do not stop if the CRL certificate is not up-to-date;
3 require an up-to-date CRL for each CA .
Default is 1.
XrdSecGSICRLDIR alternative full path to the directory containing the CRL certificates; the path can be absolute or relative to the place where the daemon is started; ‘~/’ is expanded to $HOME. Default is the same as for CA certificates.
XrdSecGSICRLEXT alternative default extension for CRL certificate files. Default is “.r0”.
xrdgsiproxy [mode] [-debug] [-f file] [-out file]
[-certdir dir] [-cert file] [-key file]
[-bits bits] [-valid valid]
[-path-length len]
Function
Stand-alone application to browse, create or destroy a user proxy certificate.
Parameters
mode
specifies the operation mode:
info display content of the proxy certificate;
init create a proxy certificate;
destroy destroy existing proxy certificate .
Default is info.
debug
run in verbose mode.
f file, out file
alternative location for the proxy file. Default is /tmp/x509up_uuid .
certdir dir
alternative directory path for trusted Certificate Authority certificates. Default is /etc/grid-security/certificates .
cert file
alternative path for the user certificate file.
Default is $HOME/.globus/usercert.pem .
key file
alternative path for the file containing the private key associated with the user certificate. Default is $HOME/.globus/userkey.pem .
bits bits
bit strength of the proxy PKI. Default is 512.
valid valid
validity of the proxy certificate. Default is 12:00, i.e. 12 hours .
path-length len
number of children generations which can originate from this proxy. Controls delegation. Use -1 for infinite. Default is 0.
sec.protocol [ libpath ] krb4 [ kfn ] [ -ipchk ] sid
Function
Define the characteristics of the krb4 authentication protocol.
Parameters
libpath
is the absolute path where the protocol shared library exists. If an absolute path is not specified, the library must be on the search path defined by the LD_LIBRARY_PATH environmental variable.
kfn
is the full pathname to the file that contains encryption and decryption keys for the protocol. The default keyfile name is protocol dependent.
ipchk
verify that the credentials presented by the client are being presented from the same host that actually obtained the credentials.
sid
is the service principal name used for authentication.
Defaults
The keyfile location is defined by Kerberos IV to be /etc/srvtab. IP checking is disabled (i.e., the host that obtained credentials need not be the same as the one that supplies the credentials).
Notes
3) The noipcheck option is provided for AFS Kerberos support (i.e., you must specify noipcheck when using AFS kerberos) as well as support for installations that wish to forward tickets from host to host.
Example
sec.protocol krb4 /etc/krb4keys xrdserv
Follow these steps to configure Kerberos IV protocol for xrootd:
5. Create a principal in the Kerberos authentication database. This principal will be the xrootd “service name”. While the default is to create a different instance[1] of the principal for every machine on which xrootd runs, it is much easier to create a single instance for all machines, especially if you have many machines.
6. Install a srvtab file containing the principal’s key string. The srvtab file may be generated by using
ksrvutil add [-a] -f filename
Substitute for filename the name of the srvtab file you wish to create or the name of an existing srvtab file to which you wish to add a key. If you are using an AFS key administration server (KAS), you must specify the –a option. You will be prompted for principal name, instance, realm, key version number, and password. Consult the man page on ksrvutil for more information.
7. Place the srvtab file in a secure location on each server.
8. In the xrootd configuration file code the protocol directive using the location of the srvtab file and the service name principal, as previously described.
9. If you are using the AFS KAS, make sure to not specify the -ipchk protocol directive option since AFS does not handle ticket IP addresses.
sec.protocol [ libpath ] krb5 [ kfn ] [ -ipchk ] sid
Function
Define the characteristics of the krb5 authentication protocol.
Parameters
libpath
is the absolute path where the protocol shared library exists. If an absolute path is not specified, the library must be on the search path defined by the LD_LIBRARY_PATH environmental variable.
kfn
is the full pathname to the file that contains encryption and decryption keys for the protocol. The default keyfile name is protocol dependent.
ipchk
verify that the credentials presented by the client are being presented from the same host that actually obtained the credentials.
sid
is the service principal name used for authentication.
Defaults
The keyfile location is defined by Kerberos V to be /etc/v5srvtab. IP checking is disabled (i.e., the host that obtained credentials need not be the same as the one that supplies the credentials).
Notes
1) The noipcheck option is provided for AFS Kerberos support (i.e., you must specify noipcheck when using AFS kerberos) as well as support for installations that wish to forward tickets from host to host.
Example
sec.protocol krb5 /etc/krb5keys xrdserv
Follow these steps to configure Kerberos V protocol for xrootd:
1. Create a principal in the Kerberos authentication database. This principal will be the xrootd “service name”. While the default is to create a different instance[2] of the principal for every machine on which xrootd runs, it is much easier to create a single instance for all machines, especially if you have many machines.
2. Install a keytab file containing the principal’s key string. The keytab file may be generated by using kadmin[3] command in Unix and the Ktpass command in Windows, as follows:
Unix:
kadmin
ktadd -k filename principal
Windows:
Ktpass –princ principal –pass pswd -out filename
Substitute for filename the name of the keytab file you wish to create or the name of an existing keytab file to which you wish to add a key. For principal, substitute the name of the principal you created in the previous step. Consult the man pages on kadmin and Ktpass for more information.
10. Place the srvtab file in a secure location on each server.
11. In the xrootd configuration file code the protocol directive using the location of the srvtab file and the service name principal, as previously described.
12. If you are using Kerberos V with AFS, make sure to not specify the -ipchk protocol directive option since AFS does not handle ticket IP addresses.
sec.protocol [ libpath ] pwd [-d:level] [-dir:dir]
[-vc:level] [-syspwd] [-maxfail:num]
[-lf:lifetime] [-a:option] [-c:list]
[-upwd:option] [-udir:dir]
[-cryptfile:file]
Function
Define the characteristics of the pwd authentication protocol.
Parameters
libpath
is the absolute path where the protocol shared library exists. If an absolute path is not specified, the library must be on the search path defined by the LD_LIBRARY_PATH environmental variable.
d:level
sets the verbosity level for this module to level; the level can be set to 1 (low), 2 (medium) or 3 (high or dump). Invoking xrootd with the verbose option –d sets the internal verbosity for this module to 1. Default is 0.
dir:dir
specifies the directory path where to look for the password file; if this directive is missing, the password file is searched for under $HOME/.xrd; the alternative directory path can be either absolute (begins with ‘/’), relative to $HOME (begins with ‘~’), or relative to directory where the daemon is started.
Examples:
-dir:/etc/xrd
make use of /etc/xrd/pwdadmin as password file
-dir:~/local/xrd
make use of $HOME/local/xrd/pwdadmin as password file
-dir:xrd
make use of $PWD/xrd/pwdadmin as password file
vc:level
Specify level of verification of client identity:
0 no additional check is done; the exchanged information packet could potentially be re-used for a reply attack.
1 verify timestamp signature; this limits the time window for reply attacks to 5 min.
2 verify random nonce signature; this choice eliminates the risk of reply attacks; it requires an additional exchange.
Default is 2.
syspwd
Instructs the server to check also the system password file; the right privileges must be owned by the server to be able to do this operation.
maxfail:num
Specifies the maximum number of unsuccessful attempts allowed before the related user tag is blocked. Option disabled by default.
lf:lifetime
Specifies the lifetime of the current password; when a time interval longer than this value is elapsed from the last the password change, the user is asked to change its password at next login. The format is
“<years>y:<days>d:<hours>h:<minutes>m:<seconds>:s”
e.g. “1y:182d:12h” for one year and a half. Lifetime is infinite by default.
a:option
Specify the set of users allowed to auto-register. Possible choices
0 none
1 users with an account on the machine (according to getpwnam) or with an enabled entry in the password file;
2 everybody.
Default is 0 .
c:list
Specifies the list of supported cryptographic modules; the default is ‘ssl|local’, with ‘ssl’ indicating the module based on OpenSSL, and ‘local’ an implementation of cipher-related functionality written by A. Pukall (http:/membres.lycos.fr/pc1/) and provided for backup in the case OpenSSL is not available.
upwd:option
Specify whether the server should also consider password files provided by users having an account on the server node; possible choices:
0 ignore user password files
1 use user password file $USERHOME/.xrd/pwduser, where $USERHOME is the user home directory as returned by getpwnam; the default subdirectory .xrd can be changed with –udir (see below).
2 check also password files with crypt-like password hashes; the default name for the file is $USERHOME/.xrdpass and can be changed with –cryptfile (see below). This option is provided mostly for backward compatibility with ROOT daemons.
Default is 0.
udir:dir
Specify alternative user sub-directory for the user password file; if existing, the file read is $HOMEUSER/dir/pwduser
Default is .xrd .
cryptfile:file
Specify alternative name for file with crypt-like password hash when option -upwd:2 has been specified. Default is .xrdpass .
Defaults
See description of each single parameter.
Example
sec.protocol pwd -a:1