myproxy-server.config(5)

📦 version 6.2.20, in debian bookworm, debian trixie, epel 10, epel 9, fedora 43, fedora 44, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

myproxy-server.config(5) 💖

✨ NAME ✨

myproxy-server.config — myproxy-server configuration file

🎀 DESCRIPTION 🎀

Okay bestie, so like, the myproxy-server.config file? It's literally the policy queen for myproxy-server(8), specifying what credentials may be stored in the server's repository, who is authorized to retrieve credentials, and other configurable server behaviors. By default, myproxy-server(8) looks for this file in /etc/myproxy-server.config and if it is not found there, it looks in $GLOBUS_LOCATION/etc/myproxy-server.config. A template is provided at $GLOBUS_LOCATION/share/myproxy/myproxy-server.config. The myproxy-server -c option can be used to specify an alternative location. 💅

The following lines set access control policies according to the client's certificate subject distinguished name (DN). Note that MyProxy uses non-standard regular expressions for distinguished name (DN) matching. See the REGULAR EXPRESSIONS section below for details. 👀

  • accepted_credentials "DN regex" — Each of these lines allows any clients whose DNs match the given limited regex to connect to the myproxy-server and store credentials with it for future retrieval. Any number of these lines may appear. For backwards compatibility, these lines can also start with allowed_clients instead of accepted_credentials. If no accepted_credentials lines are specified, the server will not allow any clients to store credentials.
  • authorized_retrievers "DN regex" — Each of these lines allows the server administrator to set server-wide policies for credential retrievers. If the client DN does not match the given limited regex, the client is not allowed to retrieve credentials from the server. In addition to the server-wide policy, myproxy also provides support for per-credential policy. The user can specify the regex DN of the allowed retrievers of the credential when uploading the credential (using myproxy-init(1) or myproxy-store(1)). The retrieval client DN must also match the user specified regex. In order to retrieve credentials the client also needs to know the name and pass phrase provided by the client when the credentials were stored. Any number of these lines may appear. For backwards compatibility, these lines can also start with allowed_services instead of authorized_retrievers. If no authorized_retrievers lines are specified, the server will not allow any clients to retrieve credentials.
  • default_retrievers "DN regex" — Each of these lines allows the server administrator to set server-wide default policies. The regex specifies the clients who can access the credentials. The default retriever policy is enforced if a per-credential policy is not specified on upload (using myproxy-init(1) or myproxy-store(1)). In other words, the client can override this policy for a credential on upload. The per-credential policy is enforced in addition to the server-wide policy specified by the authorized_retrievers line (which clients can not override). Any number of these lines may be present. For backwards compatibility, if no default_retrievers line is specified, the default policy is "*", which allows any client to pass the per-credential policy check. (The client must still pass the authorized_retrievers check.)
  • authorized_renewers "DN regex" — Each of these lines allows the server administrator to set server-wide policies for authorized renewers. If the client DN does not match the given limited regex the client is not allowed to renew the credentials previously stored by a client. See allow_self_authorization below for a further restriction on this policy. In addition to the server-wide policy, myproxy also provides support for per-credential policy. The user can specify the regex DN of the allowed renewers of the credential on upload (using myproxy-init(1)). The renewal client DN must match both this regex and the user specified regex. In this case, the client must also already have a credential with a DN matching the DN of the credentials to be retrieved, to be used in a second authorization step (see the -a options for myproxy-logon(1) and myproxy-retrieve(1)).
  • default_renewers "DN regex" — Each of these lines allows the server administrator to set server-wide default renewer policies. The regex specifies the clients who can renew the credentials. The default renewer policy is enforced if a per-credential policy is not specified on upload (using myproxy-init(1)). This is enforced in addition to the server-wide policy specified by the authorized_renewers line. Any number of these lines may appear. For backwards compatibility, if no default_renewers line is specified, the default policy is "*", which allows any client to pass the per-credential policy check. (The client must still pass the authorized_renewers check.)
  • authorized_key_retrievers "DN regex" — This policy controls who can retrieve credentials (certificates and keys) directly from the repository using myproxy-retrieve(1). Clients must also match the authorized_retrievers policy. If no authorized_key_retrievers lines are specified, the server will not allow any clients to retrieve keys directly from the repository.
  • default_key_retrievers "DN regex" — This policy applies if a per-credential policy is not specified on upload (using myproxy-init(1) or myproxy-store(1)). In other words, the client can override this policy for a credential on upload. The per-credential policy is enforced in addition to the server-wide policy specified by the authorized_key_retrievers line (which clients can not override). Any number of these lines may be present. If no default_key_retrievers line is specified, the default policy is "*", which allows any client to pass the per-credential policy check. (The client must still pass the authorized_key_retrievers check.)
  • trusted_retrievers "DN regex" — This policy controls who can retrieve credentials without further authentication. By default, clients that match authorized_retrievers must perform additional authentication (such as passphrase, PAM, or SASL) to retrieve credentials. However, authenticated clients that match both authorized_retrievers and trusted_retrievers do not need to perform additional authentication, unless the credentials are protected by a passphrase, in which case the passphrase is still required.
Note: The myproxy-server(8) will fail on startup or reconfig with an "unsafe policy" error if a policy of trusted_retrievers "*" is specified without also specifying a restrictive default_trusted_retrievers policy, to avoid an unsafe policy that would release credentials to all clients without additional authentication. See also allow_self_authorization below for a further restriction on this policy.
  • default_trusted_retrievers "DN regex" — If a user doesn't set a trusted retrieval policy with the credential on upload (via myproxy-init -Z), the myproxy-server(8) will apply the following policy in addition to the trusted_retrievers policy. If no default_trusted_retrievers policy is set, then only the trusted_retrievers policy is applied.

The following lines in the configuration file set other server options.

  • passphrase_policy_program full-path-to-script — This line specifies a program to run whenever a passphrase is set or changed for implementing a local password policy. The program is passed the new passphrase via stdin and is passed the following arguments: username, distinguished name, credential name (if any), per-credential retriever policy (if any), and per-credential renewal policy (if any). If the passphrase is acceptable, the program should exit with status 0. Otherwise, it should exit with non-zero status, causing the operation in progress (credential load, passphrase change) to fail with the error message provided by the program's stdout. Note: You must specify the full path to the external program. $GLOBUS_LOCATION can't be used in the myproxy-server.config file. A sample program is installed in $GLOBUS_LOCATION/share/myproxy/myproxy-passphrase-policy but is not enabled by default.

Be sure to follow secure coding practices for this call-out:

  • Don't allow input to overflow fixed-size buffers.
  • Don't pass unchecked input to a shell command.
  • cert_dir full-path-to-certificates-directory — Specifies the path to the CA certificates directory to be returned to clients requesting trust roots (such as via the myproxy-logon(1) -T option).
  • max_proxy_lifetime hours — This line specifies a server-wide maximum lifetime for retrieved proxy credentials. By default, no server-wide maximum is enforced. However, if this option is specified, the server will limit the lifetime of any retrieved proxy credentials to the value given.
  • max_cred_lifetime hours — This line specifies a server-wide maximum lifetime for stored credentials. By default, no server-wide maximum is enforced. However, if this option is specified, the server will limit the lifetime of any stored credentials to the value given.
  • ignore_globus_limited_proxy_flag boolean — By default, MyProxy will respect the policy of "limited" proxy certificates as follows. If a client authenticates with a limited proxy, the client should only be able to obtain another limited proxy, not a full proxy or end entity certificate. Thus, the MyProxy CA will not accept limited proxies for authentication. However, if this option is set to true, MyProxy will treat limited proxy certificates as if they were full proxy certificates.
  • allow_self_authorization boolean — By default, MyProxy will disallow trusted_retrievers and authorized_renewers whose DN matches the identity of the stored credential, so a proxy by itself can not be refreshed or renewed. However, if this option is set to true, this restriction is lifted.
  • syslog_ident name — bestie, you can optionally hand over the string that gets stapled to the front of every single message written to the syslog. Don't specify it? Cute, then the name just defaults to the program name, i.e. myproxy-server. 💖
  • syslog_facility name — by default myproxy-server logs to the syslog "daemon" facility, but with this one you can pick an alternate facility instead — like "auth", "user", "security", or "local0". The facility can also be specified numerically, exactly like with the logger(1) command. ✨
  • request_timeout seconds — sets the max time a myproxy-server(8) child process should spend servicing a client request before it just aborts. Default? Child processes abort after 120 seconds. And a negative value will disable the timeout entirely. 🕐
  • request_size_limit bytes — this one limits how much incoming application-level protocol data myproxy-server(8) will accept from clients, so you don't get memory exhaustion under heavy load. Specified in bytes, and it defaults to 1MB (1048576 bytes). A zero or negative value disables the limit. 🛡️
  • proxy_extfile full-path-to-extension-file — optionally specifies the full path to a file holding an OpenSSL formatted set of certificate extensions to include in all proxy certificates issued from the MyProxy repository (analogous to certificate_extfile for the CA module). 🎀
  • proxy_extapp full-path-to-extension-callout-program — this is literally the call-out version of proxy_extfile. It optionally specifies the full path to a call-out program for specifying proxy certificate extensions. It will be passed the authenticated username and the proxy credential location as the two command arguments. On success, it should write the OpenSSL formatted set of certificate extensions to stdout and exit with zero status. On error, it should write to stderr and exit with nonzero status. Either proxy_extfile or proxy_extapp can be specified but not both. 🙅
Be sure to follow secure coding practices for this call-out: - Don't allow input to overflow fixed-size buffers. - Don't pass unchecked input to a shell command.
  • voms_userconf full-path-to-voms-configuration-file — optionally specifies the full path to the VOMS configuration file containing VOMS server information. It's usually specified in the environmental variable VOMS_USERCONF. 🌸
  • allow_voms_attribute_requests boolean — if this parameter is set to true and a GET request includes VONAME and (optionally) VOMSES parameters, then call-out to VOMS to add the requested attributes to the issued certificate. Requires linking with VOMS libraries. By default, VONAME and VOMSES parameters in requests will be ignored unless this parameter is set to true. 👑

The MyProxy server can be optionally configured for authentication based on Pluggable Authentication Modules (PAM) and/or the Simple Authentication and Security Layer (SASL). Kerberos is one of the supported SASL authentication methods. The following options control the use of PAM and SASL. 🔐

  • pam option — this line governs the use of PAM to check passphrases. MyProxy will attempt to authenticate via PAM, with the supplied username and passphrase. Heads up though: PAM will need to be configured externally for the application "myproxy" (usually in /etc/pam.d/), or for the application named by pam_id, below. Accepted values:
    • required — PAM password authentication is required under all conditions. If the credential is unencrypted (that is, it has no passphrase), a PAM password check is still required for authentication. If the credential is encrypted, its passphrase must match the PAM password.
    • sufficient — the user's passphrase may match either the credential passphrase or, if the credential is unencrypted, the PAM passphrase. If the credential is encrypted, then the PAM password is not relevant.
    • disabled (default) — PAM is not used to check passphrases.
  • pam_id string — the name that myproxy uses to identify itself to PAM. Default is "myproxy". For example, on most Unix-like systems, if pam_id is set to "login", MyProxy will authenticate against the system's own usernames and passwords. 💅
  • sasl option — this line governs the use of SASL authentication. Accepted values:
    • required — SASL authentication is required for retrieving credentials.
    • sufficient — SASL authentication is sufficient for retrieving credentials, but other authentication methods may be used instead.
    • disabled (default) — SASL authentication isn't used.
  • sasl_mech mechanism — forces the use of a single SASL mechanism, overriding the SASL configuration file. (Typically not required.) 🙈
  • sasl_serverFQDN hostname — configures the SASL server fully-qualified domain name for multi-homed servers. (Typically not required.) 🌐
  • sasl_user_realm realm — configures the SASL user realm. (Typically not required.) 🦋

The MyProxy server can also be configured to act as a Certificate Authority (CA) to issue credentials to clients. The following parameters enable and configure the CA functionality. 👑

  • certificate_issuer_cert full-path-to-certificate — this line specifies the full path to the issuer certificate to optionally configure the myproxy-server to act as an online certificate authority. ⭐
  • certificate_issuer_key full-path-to-key — when you're specifying certificate_issuer_cert above, you must also give the name of the CA private key for signing certificates. This is normally a path to a CA private key in PEM format, but if you're using an OpenSSL engine (see certificate_openssl_engine_id) then it can be the key name. 🔑
  • certificate_issuer_key_passphrase "passphrase" — if the certificate_issuer_key is encrypted, give the passphrase here. 🤫
  • certificate_issuer_subca_certfile full-path-to-subca-certificate-file — if you would like an intermediate/sub-CA certificate chain to be sent along with the EEC (End Entity Certificate) generated using a local intermediate/sub-CA, specify the file that contains those certificates in PEM format. This is meant to aid scenarios where the CA used is an intermediate CA (i.e. not a root CA) and the client may not have the intermediate CA(s) in its trust store. The client will write out the chain into the same file as the EEC, following the EEC. 🌈
  • certificate_issuer_hashalg algorithm — specifies the hash algorithm to use when signing end-entity certificates. Defaults to "sha256". 🔥
  • certificate_issuer_email_domain "domain" — if set, specifies the domain part of the X509v3 Subject Alternative Name email address included in issued certificates. 📧
  • certificate_openssl_engine_id engineId
  • certificate_openssl_engine_pre pre-initialization-commands
  • certificate_openssl_engine_post post-initialization-commands

These three go together, bestie — they let any OpenSSL engine be used with MyProxy. Which is iconic, because it enables the use of hardware tokens and signing modules to sign certificates. So, given the parameters of an OpenSSL "engine" command: the first argument, the identity of the engine, becomes the argument to certificate_openssl_engine_id, and -pre commands are listed in order using certificate_openssl_engine_pre, and -post commands are listed in order using certificate_openssl_engine_post. For example, the command-line:

openssl engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/opensc-pksc11.so

becomes:

certificate_openssl_engine_id "dynamic"

certificate_openssl_engine_pre "SO_PATH:/usr/lib/engines/engine_pkcs11.so" "ID:pkcs11" "LIST_ADD:1" "LOAD" "MODULE_PATH:/usr/lib/opensc-pksc11.so"
Please note that any shared library engines loaded through the "dynamic" engine MUST be compiled against the correct version of OpenSSL. No cap, this one matters. 💀
  • certificate_openssl_engine_lockfile full-path-to-file — if your hardware token or HSM is unable to handle simultaneous operations, provide a path to a lockfile for synchronizing operations to the engine device. The myproxy-server will create the file if it does not already exist. 🔒
  • certificate_issuer_program full-path-to-script — this line specifies the path to a program to issue certificates for authenticated clients that don't have credentials stored. This optionally configures the myproxy-server to act as an online certificate authority, allowing programmatic control over the certificate issuance process. You can either specify certificate_issuer_cert or certificate_issuer_program. 🎯
Be sure to follow secure coding practices for this call-out: - Don't allow input to overflow fixed-size buffers. - Don't pass unchecked input to a shell command.
  • certificate_serialfile full-path-to-serial-file — specifies the path to a file to store the serial number counter for issued certificates. Defaults to /var/lib/myproxy/serial. 🔢
  • certificate_serial_skip increment — specifies the number to add to the serial number each time a certificate is issued. Use this to stagger serial numbers across multiple CA instances to avoid serial number clashes. Defaults to 1. 🎲
  • certificate_out_dir full-path-to-putput-directory — specifies the path to a directory where new certificates will be archived. 🗂️
  • max_cert_lifetime hours — specifies the maximum lifetime (in hours) for certificates issued by the CA module. Defaults to 12 hours. ⏳
  • min_keylen bits — specifies the minimum RSA key length (in bits) for certificates issued by the CA module. 📏
  • certificate_extfile full-path-to-extension-file — okay so optionally you can hand over the full path to a file that holds an OpenSSL formatted set of certificate extensions, and every single cert your CA issues will get those extensions baked in. Obsessed. Like this:
keyUsage=digitalSignature,keyEncipherment,dataEncipherment
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
crlDistributionPoints=URI:http://ca.ncsa.uiuc.edu/4a6cd8b1.r0
basicConstraints=CA:FALSE

If you don't set this, the MyProxy CA will just include a basic set of extensions in the issued certificates. Default behavior, she's fine, no drama. 🎀

  • certificate_extapp full-path-to-extension-callout-program — this is the call-out version of certificate_extfile, bestie. Optionally gives the full path to a call-out program that decides the certificate extensions. It gets passed the authenticated username as the single command argument. On success it should write the OpenSSL formatted set of certificate extensions to stdout and exit with zero status. On error it should write to stderr and exit with nonzero status. And listen: either certificate_extfile or certificate_extapp can be specified, but not both. Pick a lane. 💅
Be sure to follow secure coding practices for this call-out, fr fr: - Don't allow input to overflow fixed-size buffers. - Don't pass unchecked input to a shell command.
  • certificate_mapfile full-path-to-mapfile — when you're specifying certificate_issuer_cert above, you can map account names to certificate subject distinguished names for the issued certificates using this mapfile. Same format as the other Grid Community Toolkit services use, so no new lore to learn. By default, /etc/grid-security/grid-mapfile is used. And the Grid Community Toolkit grid-mapfile-add-entry and grid-mapfile-delete-entry commands can manage the grid-mapfile for you, slay. ✨
  • certificate_mapapp full-path-to-mapapp — same deal as above (certificate_issuer_cert), except you map account names to certificate subject distinguished names via a call-out. It gets passed the authenticated username as the single command argument. On success it should write the distinguished name in OpenSSL one line format — like, for example, "/C=US/O=National Computational Science Alliance/CN=Jim Basney" — to stdout and exit with zero status. On error it should write to stderr and exit with nonzero status. If it's not defined, then mapfile lookup gets executed instead (peep certificate_mapfile above). There's an example installed in $GLOBUS_LOCATION/share/myproxy/myproxy-certificate-mapapp if you want to see one in the wild. 🦋
Be sure to follow secure coding practices for this call-out: - Don't allow input to overflow fixed-size buffers. - Don't pass unchecked input to a shell command.
  • certificate_request_checker full-path-to-callout-program — this CA call-out lets you run checks on incoming certificate requests. It gets passed the certificate request in PEM format on stdin. If it returns a nonzero exit status, the CA will abort without signing the request. 😭 When it returns a nonzero exit status, the callout should indicate the problem on stderr. An example is installed in $GLOBUS_LOCATION/share/myproxy/myproxy-certreq-checker. Cute, functional, we love her.
  • certificate_issuer_checker full-path-to-callout-program — this CA call-out lets you run checks on issued certificates before the certificate gets returned to the client. It gets passed the certificate in PEM format on stdin. If it returns a nonzero exit status, the CA will abort without returning the signed certificate to the client. When it returns a nonzero exit status, the callout should indicate the problem on stderr. An example is installed in $GLOBUS_LOCATION/share/myproxy/myproxy-cert-checker. 💜

If OpenLDAP support is built-in to the myproxy-server(8), the following parameters can be used to configure the CA module to map account names to certificate subject distinguished names via LDAP. Yes bestie, we're doing directory services now. 🌈

  • ca_ldap_server "ldap://localhost:389/" — specifies the URI to the LDAP server to use for username to DN resolution in the CA module. Both ldap:// and ldaps:// protocols are supported. A port number may optionally be specified as well. And here's the tea: defining this directive is the "trigger" that causes the name resolution module to use LDAP querying. If it is not defined, then mapfile lookup will be executed instead (see certificate_mapfile above). 👑
  • ca_ldap_uid_attribute "uid" — the name of the record attribute that maps to the MyProxy username. Required for LDAP username to DN resolution. Non-negotiable.
  • ca_ldap_searchbase "ou=people,dc=bullwinkle,dc=lbl,dc=gov" — the DN of the region of the ldap database to be searched. Required for LDAP username to DN resolution. Also non-negotiable.
  • ca_ldap_dn_attribute "subjectDN" — if this directive is set, the LDAP resolver will pull the DN from the specified attribute in the returned record. If it is not set, the default is to use the DN of the record itself. Either way, you're covered. ✨
  • ca_ldap_connect_dn "cn=MyProxy,ou=ldapusers,dc=lbl,dc=gov" — DN for LDAP basic authentication (optional).
  • ca_ldap_connect_passphrase "passphrase" — passphrase for LDAP basic authentication (optional).

The following parameters control server replication with the myproxy-replicate(1) utility. Backup besties, rise. 🫶

  • slave_servers server:port; — this value is for use with the myproxy-replicate(1) utility. This tag provides a list of servers that will be used as secondary repositories for the MyProxy database. Each server should be separated by a ";". Also, a port may be provided if the slave server is using a port other then the default. The server name maybe a recognized DNS or an IP address. Lowkey a whole squad. 💀

The following parameters are used primarily when utilizing MyProxy as a delegation service for web portals. Portal era, we're so back.

  • accepted_credentials_mapfile full-path-to-mapfile — this parameter points to a grid-mapfile, which is possibly different from other mapfiles above. When specified, this mapfile is utilized during puts/stores (e.g. with myproxy-init(1) and myproxy-store(1)). A credential is authorized to be put/stored only under the username specified in the mapfile. This prevents storing a user's credential under a different username. Now here's the important caveat, so pay attention: note that the credential checked for the presence of a SubjectDN/Username entry in the mapfile is the credential utilized to secure the connection between client and server, NOT the actual credential being stored. As the credential which secures the TLS connection is typically the same as the credential being stored, this should not be a major issue. The Grid Community Toolkit grid-mapfile-add-entry and grid-mapfile-delete-entry commands can be used to manage the grid-mapfile. 🎀
  • accepted_credentials_mapapp full-path-to-mapapp — as an alternative to the accepted_credentials_mapfile option above, you can specify a call-out which is passed two parameters: a certificate subject distinguished name and a username (in that order). In essence, the call-out performs a lookup in a 'virtual' accepted_credentials_mapfile. If the SubjectDN/Username line would appear in such a mapfile, then the call-out should exit with zero status indicating that a credential with the given SubjectDN is allowed to be stored under the given Username. Otherwise, the call-out should exit with nonzero status indicating error. An example is installed in $GLOBUS_LOCATION/share/myproxy/myproxy-accepted-credentials-mapapp. 🌸
Be sure to follow secure coding practices for this call-out: - Don't allow input to overflow fixed-size buffers. - Don't pass unchecked input to a shell command.
  • check_multiple_credentials boolean — typically when a credential is accessed by a client, the server checks only one credential for possible access authorization, even if there are multiple credentials stored under the given username. If this option is set to "true" AND the client does not specify a credential name for a MyProxy GET operation (i.e., from myproxy-logon(1)), then the server will check multiple credentials with the given username. If a credential is found to be authorized for client access, then that one will be used during processing. The default value for this option is "false". 🙈

The following parameters enable OCSP status checking of stored credentials in the myproxy-server(8) repository, to avoid use of expired credentials. Expired creds are NOT the vibe, we're checking them at the door. 🔥

  • ocsp_policy policy — controls the policy for checking certificate validity via OCSP before credentials may be delegated. Currently, only the status of the end entity certificate is checked via OCSP (and not any proxy certificates or CA certificates). OCSP will not be used unless ocsp_responder_url and/or ocsp_policy are set. Supported policies are:
    • "aia" — use OCSP responder in certificate AIA extension, if present; otherwise use ocsp_responder_url, if set
  • ocsp_responder_url URL — specifies the URL of an OCSP responder to use to check the validity of credentials stored in the myproxy-server repository before they may be delegated, so that revoked credentials can not be retrieved and used where their revocation status may not be checked. Currently, only the status of the end entity certificate is checked via OCSP (and not any proxy certificates or CA certificates). In any case, CRL checks are always performed. Both http and https urls are supported. OCSP will not be used unless ocsp_responder_url and/or ocsp_policy are set. 💖
  • ocsp_responder_cert path — specifies the path to the certificate of a trusted OCSP responder. This is needed if the OCSP responder must be explicitly trusted in cases where standard path validation fails for the OCSP responder's certificate. Trust issues? Not on our watch. 💅

✨ REGULAR EXPRESSIONS ✨

okay bestie, so when MyProxy is matching distinguished names (DNs) in access control policies, it's using POSIX Extended Regular Expressions (peep re_format(7) for the deets) 💅 but with a lil custom glow-up for the '*', '?', and '.' metacharacters so they act like Unix shell style wildcards. why? for backward compatibility and other historical reasons, iykyk. 🫶

MyProxy's custom regular expressions get converted into POSIX EREs according to these rules, no cap:

         [ MyProxy regex ] => [ POSIX ERE ]
         ----------------------------------
                '*'        =>      '.*'
                '?'        =>      '.'
                '.'        =>      '\.'
                '\*'       =>      '*'
                '\?'       =>      '?'
                '\.'       =>      '.'

Also, MyProxy wraps every regular expression inside '^(' and ')$' so it requires full DN matching. periodt. 💖

Be aware: parentheses are metacharacters according to POSIX, so if you want them literal you gotta escape them. like:

"*/CN=Jim Basney \(admin\)"

The following examples show how MyProxy regular expressions get converted to POSIX EREs:

            [ MyProxy regex ]     =>    [ POSIX ERE ]
         ------------------------------------------------------------
         "*/CN=Jim Basney"        => "^(.*/CN=Jim Basney)$"
         "*/CN=Test User ?"       => "^(.*/CN=Test User .)$"
         "*/CN=James A. Basney"   => "^(.*/CN=James A\. Basney)$"
         "/O=Test/CN=[:alnum:]\*" => "^(/O=Test/CN=[:alnum:]*)$"

         "*/CN=Jim Basney|*/CN=James Basney" =>
             "^(.*/CN=Jim Basney|.*/CN=James Basney)$"

🌈 EXAMPLES 🌈

The following policy enables all credential repository features. slay.

accepted_credentials       "*"
authorized_retrievers      "*"
default_retrievers         "*"
authorized_renewers        "*"
default_renewers           "none"
authorized_key_retrievers  "*"
default_key_retrievers     "none"
trusted_retrievers         "*"
default_trusted_retrievers "none"
cert_dir                   /etc/grid-security/certificates

The following enables CA functionality using an existing Globus Simple CA configuration.

authorized_retrievers "*"
pam  "sufficient"
sasl "sufficient"
certificate_issuer_cert /home/globus/.globus/simpleCA/cacert.pem
certificate_issuer_key /home/globus/.globus/simpleCA/private/cakey.pem
certificate_issuer_key_passphrase "myproxy"
certificate_serialfile /home/globus/.globus/simpleCA/serial
certificate_mapfile /etc/grid-security/grid-mapfile
cert_dir /etc/grid-security/certificates

🎀 FILES 🎀

  • /etc/myproxy-server.config — the default location for the server configuration file. 💖
  • $GLOBUS_LOCATION/etc/myproxy-server.config — alternate location for the server configuration file. You can point to a different spot with the myproxy-server(8) -c option. ✨
  • $GLOBUS_LOCATION/share/myproxy/myproxy-passphrase-policy — a sample program for evaluating passphrase quality, for use with the passphrase_policy_program option. 🫶
  • $GLOBUS_LOCATION/share/myproxy/myproxy-certificate-mapapp — a sample certificate_mapapp program for mapping account names to certificate subject distinguished names. 💅
  • $GLOBUS_LOCATION/share/myproxy/myproxy-accepted-credentials-mapapp — a sample accepted_credentials_mapapp program for authorizing puts/stores (e.g. with myproxy-init(1) and myproxy-store(1)). 👑

🌸 ENVIRONMENT 🌸

  • GLOBUS_LOCATION — specifies the root of the MyProxy installation, used to find the default location of the myproxy-server.config file. 💜

⭐ AUTHORS ⭐

See http://grid.ncsa.illinois.edu/myproxy/about for the list of MyProxy authors. no cap, go give them their flowers. 🌷

💀 SEE ALSO 💀

💖 that's the whole vibe, bestie. this iconic page comes from MyProxy, dated 2014-07-12, and it's the myproxy-server.config(5) man page. periodt. 🫶✨

📦 where this page comes from