DACSRLINK(1)                  DACS Commands Manual                  DACSRLINK(1)

       dacsrlink - create and administer rule links

       dacsrlink [dacsoptions[1]] op [arg...]

       This program is part of the DACS suite.

       The dacsrlink command is used to create and manage specially constructed
       URLs called Rlinks (rule links). Briefly, an Rlink is a URL that includes
       a special component called an Rname. The Rname identifies a specific DACS
       access control rule that is to be used with the URL, disabling the usual
       ACL searching algorithm for the request. Although no searching for the
       rule is done, the named ACL must still exist and match the request, such
       as through a suitable url_pattern. As with any access control rule,
       arbitrary expressions can be evaluated before access to the URL is
       allowed (or denied), including client redirection.

       An Rlink is handled by dacs_acs(8)[2] during authorization checking.
       Because ACL searching is not performed for the request, Rlink processing
       can be more efficient. While the syntax of these rules is identical to
       that of normal access rules (acl.dtd[3]), not administered by
       dacsacl(1)[4] and they are not indexed.

       A given resource may be referenced by Rlinks with different Rnames. Each
       instance of an Rlink for the resource may therefore have different access
       rights or cause different side effects. Depending on the application, the
       creator of an Rlink may expect it to be kept secret by everyone that
       receives it, resulting in a weak (though often sufficient) method of
       access control.

       There are many applications of Rlinks. They can be used to provide:

       •   identity-restricted access to a resource without having to create
           per-identity accounts; when the Rlink is invoked (optionally
           accompanied by a password bound to the URL), the identity is
           available to the access control rule and an invoked web service just
           as if "real" DACS credentials had been used;

       •   a convenient, user-friendly acknowledgement mechanism that has a weak
           degree of security; e.g., by creating a link that a user can click on
           to continue an account registration step or confirm reading a
           licensing agreement;

       •   a link that can be used for user tracking;

       •   a way to override or customize another rule without modifying the
           original rule;

       •   access to a resource with per-user constraints; e.g., to restrict
           access to a file or application for a particular user to a given
           time, date, or duration;

       •   a simple front end for creating ordinary access control rules.

       A DACS identity may be attached to an Rlink through the command's rlink
       and rname operations. When an Rlink with an attached identity is used,
       that identity is available to dacs_acs[2] for access control purposes.
       There are two modes of attachment: direct and indirect. Identities for
       use with the direct mode are encrypted using the jurisdiction_keys item
       type (see dacskey(1)[5]); the program's user must therefore be able to
       read these keys. Changing these keys will invalidate all existing
       encrypted identities. Refer to the imode[6] flag for details.

       The identity associated with an Rlink need not exist outside of its use
       by the Rlink.

       The special, temporary credentials associated with an Rlink have the
       authentication style "rlink" (refer to user()[7] with the style keyword),
       but not passwd, even if a password is required to gain access to a

       For additional information, refer to the description of the RLINK[8]
       configuration directive and dacs_acs(8)[9].

       dacsrlink recognizes the standard dacsoptions[1], which are immediately
       followed by an operation name (op), various operation-dependent flags,
       and finally non-flag arguments. The -- flag can be used to terminate the
       operation-dependent list of flags. Flags that are not recognized by the
       selected operation are ignored. A rule is always syntax checked (as by
       dacsacl(1)[4]) before being written; if an error is found, the operation
       is aborted. Several flags are recognized by more than one operation.

       By default, the virtual filestore item type rlinks specifies where Rlinks
       are stored. This can be overridden for most operations by giving the -vfs
       flag, which can specify a DACS URI, alternate item type, or absolute

           Access to the rules and to listings of their names must be
           restricted, otherwise Rnames could be revealed. Only a DACS
           administrator should be permitted to list, create, modify, delete,
           etc. rules.  dacs_acs must be able to access the rules if Rlinks are
           enabled. Ensure that file permissions are set appropriately.

       The optional -out flag is followed by a filename to which the rule should
       be written instead of a filestore. If "-" is given as the filename, the
       standard output is used.

       The default alphabet used to generate Rnames can be overridden using the
       -ralpha flag; alpha, which follows the flag, is a character specification
       in the syntax of strtr()[10] (e.g., "a-zA-Z0-9", which is the default).
       The default length of an Rname can be overridden using the -rlen flag.
       Alternatively, some operations take a -rname flag that specifies the
       Rname to use.

       The following op arguments are understood:

           Perform a syntax check on the rule identified by rname to the
           standard output. If no error is found, an exit status of 0 is
           returned, otherwise an error message is produced and 1 is returned.

           Create a new Rname that is virtually identical to that of rname (only
           the name differs). If the -rname flag is given, use rname as the
           Rname instead of generating one.

              [{-a | -allow}name] [{-p password} | {-pf file}]...
              [-palg alg-name] [-r redirect-URL] [-rname rname] [-ralpha alpha]
              [-rlen len]
              [-expires {seconds | date}] path...
           Create a new, enabled Rlink and write it to either the filestore, a
           specified file, or the standard output. The optional -a (or -allow)
           flag is followed by name, which is a string that will become the
           argument to the user()[11] function that will be called from the
           allow clause of the ACL that is created. Each name will therefore be
           granted access to each of the named path arguments, which are URI
           path components relative to the current jurisdiction.

           A password that applies only to this user can optionally follow as
           the next argument using a -p or -pf flag; its hashed value will be
           embedded in the Rlink and compared against a hash of an argument
           named PASSWORD that must be submitted with the Rlink. If a -p or -pf
           flag precedes any -a (-allow) flag, however, it establishes a default
           password for all users specified later on the command line. The -pf
           flag is followed by a filename from which the password is read; if
           file is "-", the password is read from the standard input. A password
           may be specified even if no -a flag is present; the request will not
           have an identity bound to it but a valid PASSWORD argument must be
           provided. The -palg flag overrides the default password hashing
           algorithm (see password()[12]).

           If the -rname flag is given, rname is used as the Rname instead of
           generating one. The -expires flag assigns an expires_expr attribute
           to the Rlink, which will render the Rlink invalid after the specified
           date. The flag is followed either by an unsigned integer, which is
           interpreted as a number of seconds in the future, or a date in one of
           the recognized formats[13].

           If the -r flag appears, no usernames can be specified. An attempt to
           access any of the resources associated with the Rlink will cause the
           client to be redirected to redirect-URL, which may contain a properly
           encoded query component. This lets an Rlink serve as a "short link",
           akin to the services provided by bitly.com[14], TinyURL.com[15], and
           many others. Refer to the redirect()[16] function for additional

               Administrators should review the rule that is created. The
               show[17] operation can be used to display the rule and the
               edit[18] operation can be used to modify it.

           Delete the Rname named rname in the selected filestore. This will
           effectively nullify all Rlinks that reference rname. To temporarily
           disable all Rlinks that reference an Rname, edit the rule and change
           its status attribute to disabled.

           Interactively edit a copy of the rule named rname in the selected
           filestore. If the environment variable EDITOR is set, it is used as
           the name of the editor to use, otherwise the compile time symbol
           DEFAULT_EDITOR is used. When editing is completed, the rule is
           replaced with the edited copy, provided the new version is
           syntactically correct.

           Decode and print rname-ident, an Rname with an identity component
           produced by the rlink or rname operations.

           Print a listing of all Rnames in the selected filestore.

           Emit an Rlink to the standard output that integrates rname into the
           uri according to link-mode. The link-mode is one of dacs_acs (or just
           acs), query, or path, representing the three general forms of an
           Rlink. If ident is specified, it describes a user in the concise user
           syntax[19] that is associated with the link. The ident may include an
           expiry date.

           The -imode specifies whether a direct or indirect identity should be
           associated with the Rname, or whether there is none (the default).
           For direct, ident (specified by -i or -ident) is used; it describes
           an identity in the concise user syntax[19] that is associated with
           the link. For the indirect mode, a random identifier is generated
           (using the same algorithm selected for Rnames); if the -iptr flag is
           given, however, iptr is used as the identifier string.

           If uri is a URI path component (i.e., it begins with a '/'), the
           configuration variable rlink_base_prefix must be defined; its value
           is prepended to the URI path.

           Additional query arguments can be attached to the emitted link. If a
           password is required by the ACL for the resource, for example, a
           PASSWORD argument is required.

           Implementation of query and path modes is incomplete, so URLs for
           those Rlinks must be generated manually.

             [-rname rname]
           This operation emits an Rname that satisfies the given constraints
           and prints it to the standard output. The Rname is suitable for use
           with the -rname flag. It does not create an ACL. This operation might
           be useful when Rlinks are created manually or using another program.

           The -imode, -i, and -iptr flags are as described for the rlink

           Print the rule identified by rname to the standard output.

       The following examples assume that the jurisdiction EXAMPLE includes the
       following configuration:

           RLINK '"${Args::RNAME:?}" /usr/local/dacs/rlinks'
           EVAL   ${Conf::rlink_base_prefix} = "https://www.example.com"
           VFS    "[rlinks]file:///usr/local/dacs/rlinks"

       These directives enable Rlink processing by dacs_acs(8)[2] and cause URLs
       generated by dacsrlink to be prefixed by https://www.example.com. ACLs
       that it creates will be stored as files in the /usr/local/dacs/rlinks

       This command creates an Rname called IRCl7p4Q, and associates it with the
       relative URL /cgi-bin/dacs/dacs_prenv. The Rname will expire in 300
       seconds (relative to this jurisdiction's clock):

           % dacsrlink -uj EXAMPLE create -expires 300 /cgi-bin/dacs/dacs_prenv

       Once an Rname has been created, a URL can be generated that incorporates
       the Rname:

           % dacsrlink -uj EXAMPLE rlink -lmode acs IRCl7p4Q /cgi-bin/dacs/dacs_prenv

       In this example, the Rname has been incorporated into the URL through the
       DACS_ACS argument[20].

       To display the ACL for Rname IRCl7p4Q:

           % dacsrlink -uj EXAMPLE show IRCl7p4Q
           <acl_rule status="enabled" name="IRCl7p4Q" expires_expr='time(now) ge 1178917167'>
               <service url_pattern="/cgi-bin/dacs/dacs_prenv"/>

             <rule order="allow,deny">

       Or, since the access control rule created by dacsrlink can be found in

           % cat /usr/local/dacs/rlinks/IRCl7p4Q

       The default rule for dacs_prenv(8)[21] restricts access to a DACS
       administrator, but anyone who uses this Rlink before it expires will be
       granted access to dacs_prenv. This rule can be manually customized at
       anytime. Note that unlike ordinary access control rules, there is no
       index file for Rlinks.

       Suppose Rname 8D8m5CTj is this ACL:

           <acl_rule status="enabled" name="8D8m5CTj">
               <service url_pattern="/cgi-bin/dacs/special"/>

             <rule order="allow,deny">
               if (${Args::EMAIL} == "bob@example.com") {
                 redirect(BY_SIMPLE_REDIRECT, "http://dss.ca")
               else {
                 redirect(BY_SIMPLE_REDIRECT, "http://metalogicsoftware.ca")

       While it is not required to use dacsrlink, a command like the following
       might be used to conveniently construct a URL:

           % dacsrlink -uj EXAMPLE rlink -lmode acs 8D8m5CTj '/cgi-bin/dacs/special?EMAIL=bob@example.com'

       In this example, a user who submits the link would be redirected to
       http://dss.ca. As usual, a resource corresponding to the path
       /cgi-bin/dacs/special does not need to actually exist at the
       jurisdiction. This ACL can be generalized to examine the request and
       other context and perform arbitrary actions, perhaps by using an external
       program - see exec()[22]. A linkback[23] can be implemented in this way,
       for instance.

       This command creates a rule that applies to two resources and grants
       access to two users:

           % dacsrlink -uj EXAMPLE create -a :auggie -a :harley /private/a.html /private/b.html
           % dacsrlink -uj EXAMPLE show 7tW3SJou
           <acl_rule status="enabled" name="7tW3SJou">
                 <service url_pattern="/private/a.html"/>
                 <service url_pattern="/private/b.html"/>
             <rule order="allow,deny">

       To generate URLs to give to these two users so that they can access these
       resource, commands like the following would be used:

           % dacsrlink -uj EXAMPLE rlink -imode direct -i ":auggie" -lmode acs 7tW3SJou /private/a.html
           % dacsrlink -uj EXAMPLE rlink -imode direct -i ":harley" -lmode acs 7tW3SJou /private/b.html

       When the first of these links is invoked, it will appear as if
       EXAMPLE:auggie is accessing a.html. Since no expiration was specified for
       the identities or the resources, the two links will be valid
       indefinitely. The rule can be deleted at any time:

           % dacsrlink -uj EXAMPLE delete 7tW3SJou

       This demonstrates how to create a password-controlled link:

           % dacsrlink -uj EXAMPLE create -a :auggie -p abracadabra /private/c.txt
           % dacsrlink -uj EXAMPLE show rIPZaJeN
           <acl_rule status="enabled" name="rIPZaJeN">
                 <service url_pattern="/private/c.html"/>
             <rule order="allow,deny">
                  and password(check, ${Args::PASSWORD}, "2|XYZZYnahdnl3VtLqGtpbW|2GoDncq34p2EMO4PA5Uj6iWkFb9")
           % dacsrlink -uj EXAMPLE rlink -imode direct -i :auggie -lmode acs rIPZaJeN /private/c.txt
           % dacshttp "https://www.example.com/private/c.txt?DACS_ACS=-rname+rIPZaJeN:r6RdcTcmUyhTtgbtJg&PASSWORD=abracadabra"
           Hello, world

       The program exits 0 if everything was fine, 1 if an error occurred.

       dacs.acls(5)[24], dacs_acs(8)[2]

       Distributed Systems Software (www.dss.ca[25])

       Copyright © 2003-2014 Distributed Systems Software. See the LICENSE[26]
       file that accompanies the distribution for licensing information.

        1. dacsoptions

        2. dacs_acs(8)

        3. acl.dtd

        4. dacsacl(1)

        5. dacskey(1)

        6. imode

        7. user()

        8. RLINK

        9. dacs_acs(8)

       10. strtr()

       11. user()

       12. password()

       13. recognized formats

       14. bitly.com

       15. TinyURL.com

       16. redirect()

       17. show

       18. edit

       19. concise user syntax

       20. DACS_ACS argument

       21. dacs_prenv(8)

       22. exec()

       23. linkback

       24. dacs.acls(5)

       25. www.dss.ca

       26. LICENSE

DACS 1.4.40                        02/19/2019                       DACSRLINK(1)