DACSCHECK(1) | DACS Commands Manual | DACSCHECK(1) |
NAME¶
dacscheck - authorization checkSYNOPSIS¶
dacscheck [-admin]
[-app appname] [
-context file] [
-Dname=value]
[ -F field_sep]
[-fd domain] [
-fh hostname] [
-fj jurname] [
-fn fedname]
[ -dump] [-groups group_vfs] [-h]
[-i ident]
[-il ident]
[ -ilg ident] [-ieuid] [-ieuidg]
[-iuid] [ -iuidg] [-lg]
[-ll log_level] [
-name_compare method] [-q]
[ -redirect] [-roles roles_vfs]
[-rules rule_vfs] [-v]
[-var name=value]
[ -vfs vfs_uri] [--] object
DESCRIPTION¶
This program is part of the DACS suite. It is a stand-alone program that neither accepts the usual DACS command line options ( dacsoptions) nor accesses any DACS configuration files. Put simply, dacscheck looks at access control rules to test if a given user is authorized to do something or access something. The command's exit status gives the result of the test, and unless the -q flag is given, a line is printed to stdout that indicates the result. It provides simplified, general-purpose access to DACS's access control rule evaluation engine, even for programs other than web services, and it lends itself to fine-grained access control decisions. More specifically, dacscheck checks if a request for object should be granted according to specified access control rules and a given evaluation context. To do its job, dacscheck needs to know only a few things: 1.where to find the access control rules to apply;
2.the name of the object being accessed; and
3.optionally, an evaluation context that specifies an
identity for which access is being tested and variables that can be referenced
by rules.
The command does not perform any authentication; it assumes that the caller (or
the execution environment) has already established the identity for which an
access control decision is required. It may be used like any other command:
run from the command line or a shell script, executed by a compiled program,
or called from a scripting language such as Perl[1], PHP[2].
Python[3], Ruby[4], and Tcl/Tk[5].
Some simple examples will illustrate how dacscheck can be used.
#! /bin/sh dacscheck -q -ieuid -rules /usr/local/myapp/rules /myapp st="$?" if test "${st}" != 0 then echo "Access is denied" exit "${st}" fi echo "Access is granted" # Do some stuff exit 0
<acl_rule status="enabled"> <services> <service url_pattern="/myapp"/> </services> <rule order="allow,deny"> <allow> user(":bob") or user(":alice") </allow> </rule> </acl_rule>
% dacsacl -un -vfs "[acls]file:///users/bobo/my-rules" -vfs "[dacsacls]:file:///dev/null"
#! /bin/sh if test "${REMOTE_USER}x" = "x" then idarg="" else idarg="-i ${REMOTE_USER}" fi echo "Context-Type: text/plain" echo "" # Note: append 2>&1 to the end of the next line to capture error messages dacscheck -q ${idarg} -rules /usr/local/myapp/rules /myapp st="$?" if test "${st}" = 0 then echo "Access is granted" else echo "Access is denied" fi exit 0
$user = $_SERVER["REMOTE_USER"]; putenv("REMOTE_USER=$user"); system("/usr/local/dacs/bin/dacscheck -q -fn DEMO -icgi -rules /usr/local/myapp/rules /myapp", $st); if ($st != 0) { // Access is denied, bail out exit($st); } // Access is granted, proceed
•Using FreeBSD's ACLs[14], Dru Lavigne,
ONLamp.com[15], 22-Sep-05.
•POSIX ACLs in Linux[16], Mike Peters,
linux.com[17], 2-Aug-04.
•For Solaris, Solaris 10 acl(2)[18], Sun
Microsystems[19] and Using Solaris ACLs[20] by the Dept. of
Computer Science, Duke University[21].
if ($logged_in_as_root || $logged_in_as_current_admin) { # Do something privileged... }
# Determine if $username has admin privileges $output = `dacscheck -q -i $username -app myapp /myapp/admin`; $is_admin = ($? >> 8) == 0; if ($is_admin) { # Do something privileged... } # Later... if ($is_admin) { # Do something else privileged... }
<acl_rule status="enabled"> <services> <service url_pattern="/myapp/admin"/> </services> <rule order="allow,deny"> <allow> user("%:admin") </allow> </rule> </acl_rule>
Advantages¶
Programs that perform authorization tests typically contain code like:•"If the current user has provided a suitable
password, then execute the following code, otherwise do not", or
•"If the current user is the administrator,
do the following", or
•"If the current user is allowed to perform
an update operation, then show these menu items, otherwise do not show
them"
Complicated applications can be littered with these kinds of tests, making them
prone to bugs and security problems. Changes to security policies may involve
modifications throughout an application or suite of applications. Also,
password handling is often incorporated into such programs; because password
management can require a significant implementation effort and is difficult to
do securely, it seems wise to try to leverage existing implementations.
Compared to custom-coded solutions, dacscheck has many advantages:
Data-driven policies
As opposed to specially-written access control logic,
data-driven (rule-based) functionality is superior because:
Programming Efficiency
•Access control rules are separate from code, so
changes to a set of rules automatically applies to all uses of those rules
throughout an application or set of applications; code does not need to be
modified if the policy is changed.
•Bug fixes and improvements to rules are
automatically available to programs that use dacscheck; no
recompilation of applications is necessary.
•The person who administers the rules does not
have to be the application's programmer (or even someone who understands the
code), so delegating responsibility is much easier. This reduces the amount of
programming required when changes are required, reduces code maintenance
effort, and decreases the chance of error.
•It is usually easier to understand (and express)
a set of rules that describes an access control policy; code that implements
the same policy will be more complex and difficult to understand, increasing
the chance of error.
•Applications are simplified and programming time
and effort are reduced because existing access control code (i.e.,
dacscheck) is reused.
•Sophisticated rules can be constructed without
having to write any code. DACS features are available, such as roles
and groups, and can be used to construct simpler and more expressive
authorization policies than are likely to be hand-coded.
Rules are platform independent, can be stored remotely
from the applications that use them, and can potentially be evaluated
remotely. dacscheck is available for a variety of platforms.
Increased Sharing
Rules can be shared and used in different situations and
by different programs.
Flexibility
•Because it does not rely on a web server, it can
be used by virtually any CGI-based program.
•With respect to DACS, it can be used in
circumstances where the mod_auth_dacs[25] module cannot be used with
Apache, or where Apache cannot be used at all.
•Because it is implemented as an ordinary command,
dacscheck can be used from the command line or invoked from almost any
script or program.
•For CGI-based programs, dacscheck can be
used without any assistance from a system administrator; e.g., it does not
require a web server to be configured to provide authorization for a CGI
program because all access control functionality is performed within the
program.
dacscheck neither performs authentication nor
relies on any particular authentication method, so the authentication method
can be changed without affecting the application's use of dacscheck.
Any supported means of authentication can be used, not only the typical
password-based method.
While the performance of dacscheck ought not to be a factor for many
applications, the C/C++ API can be used where it is an issue. This API can be
used to incorporate dacscheck functionality into compiled programs and
extensible languages, such as Perl, Python, Tcl/Tk, and
PHP.
Identities¶
The identity for which access is to be tested is given to the program or obtained by the program from its execution environment. This identity is converted into DACS's internal representation. More than one identity can be specified; the check is made on behalf of the union of all the identities. If the identities bob and alice are specified, for instance, a rule that is satisfied by either identity may grant access. If no identity is given, the check is made on behalf of an unauthenticated user. An identity can be:•a login name that dacscheck maps to from
the real or effective uid of the program (i.e., the user who is running the
program);
•a DACS user identity (e.g., :carol,
DSS:bob, or EXAMPLE-COM::DEMO:alice, see dacs(1)[26]);
•a simple name (bob is equivalent to :bob);
or
•a name expressed in the concise
syntax[27], which gives a username and, optionally, roles and attributes
for the identity. Any identity that has expired is not used.
•dacscheck validates the syntax of an
identity it is given, converts and expands it to the concise syntax if
necessary, and then converts it into its internal representation for
credentials. These credentials are destroyed when the program terminates.
Regardless of how it is specified, each identity must satisfy the syntactic
requirements of a DACS user identity after this conversion and
expansion (see dacs(1)[26]). If a login name is specified as an
identity, for example, it must be valid as a component of a DACS user
identity; therefore, it cannot contain any invalid characters.
•If no IP address is provided for an identity, it
is obtained from the REMOTE_ADDR environment variable when available,
otherwise a default of 127.0.0.1 is used. The IP address associated with
credentials is tested using the user() predicate.
•If an identity that is being tested includes a
federation name, since the default federation name is unlikely to be correct,
it will probably be necessary to tell dacscheck which federation name
to compare against using the -fn flag.
bob :bob DSS:bob {u = bob} {u="bob"} {u="alice",g="admin"} {u="DSS:bob",g="guest"} {u="bob",a="a", g="guest"}
-i '{u="bob"}'
•${Conf::FEDERATION_NAME} and
${DACS::FEDERATION} are both set to EXAMPLE-COM (dots are mapped to
dashes to form a valid name)
•${Conf::FEDERATION_DOMAIN} is set to
EXAMPLE.COM
•${Conf::JURISDICTION_NAME} and
${DACS::JURISDICTION} are set to the jurisdiction name, DEMO
•${DACS::HTTP_HOST} is set to
demo.example.com:80
Often, rules and identities can be expressed such that the names chosen for the
federation and jurisdiction are unimportant. When this is not the case,
however, and the defaults chosen by dacscheck are incorrect, they can
be set on the command line. In some circumstances it might be appropriate for
the jurisdiction name to be the name of the application, for example.
Regardless of their origins, federation and jurisdiction names must always be
syntactically valid (see dacs(1)[26]).
Objects¶
While an object will often be an actual thing, such as a file, menu, or variable, it can also be an abstraction, such as an operation. dacscheck works with names - in the form of URIs - rather than objects per se. It does not associate any particular meaning with names, it merely uses them to locate an applicable access control rule. Therefore, provided the rule writer and applications that consult the rules agree on the naming scheme, the names that are chosen are largely irrelevant. An application assigns names to every object or class of objects that need to be referenced by access control rules. At its simplest, only one name is required (the name of the application, for example). In more complex situations, a wide variety of objects need to be named. The choice of names and the details of the naming hierarchy are up to the particular application, much like the organization of a software package's run-time file and directory organization depends on the particular package. The object argument is the name that is matched against the services specified in access control rules. It can be either a URI or an absolute pathname (one that begins with a slash character), and either can have an optional query string component attached. An absolute pathname path is mapped internally to a URI as file:// path; e.g., /myapp is interpreted as file:///myapp (see RFC 1738[30]). The various components of the URI that names the object are available as DACS variables and environment variables (see below). If a query string is given, it is parsed and the individual arguments are made available to rules through the Args namespace, just as for DACS-wrapped web services.Rule Evaluation Context¶
Rules are evaluated within an execution context that may affect expression evaluation implicitly or may be examined explicitly through variables. Since dacscheck does not consult the DACS configuration files, the Conf namespace is instantiated with few variables. At present, only the VFS directives are available in it. The Args namespace is instantiated if an object argument has a query string component. The DACS namespace is instantiated with a few standard variables (such as ${DACS::JURISDICTION}) but can also be instantiated in various ways from the command line and from files. The Env namespace is instantiated from the environment. Syntactically invalid variable names are silently ignored. Many variables normally set by a web server are instantiated by dacscheck based on the object name. These variables are available in the Env and DACS namespaces. For example, if the object name is https://example.com:8443/myapp/edit-menu?entry=item1, the following variables will be set as indicated:${Env::HTTPS}=on ${Env::SERVER_NAME}=example.com ${Env::SERVER_ADDR}=142.179.101.118 ${Env::HTTP_HOST}=example.com:8443 ${Env::SERVER_PORT}=8443 ${Env::REQUEST_URI}=/myapp/edit-menu ${Env::DOCUMENT_ROOT}=/ ${Env::REQUEST_METHOD}=GET ${Env::SERVER_SOFTWARE}=dacscheck-1.4.8b ${Env::QUERY_STRING}=entry=item1 ${Env::ARG_COUNT}=1 ${Env::CURRENT_URI}=/myapp/edit-menu?entry=item1 ${Env::CURRENT_URI_NO_QUERY}=/myapp/edit-menu
An Example Application¶
To illustrate how the pieces fit together, let's consider a hypothetical (yet realistic) calendar application named cal that is written in Perl and invoked as a CGI program. We'll allow a user that has been authenticated by the web server to read, create, or update only her own calendars, unless the owner of a calendar gives her permission to perform a read or update operation on the calendar. Each owner can specify which users have access to her own calendar and the type(s) of access allowed. This authorization policy can be specified fairly easily. One approach is to use:•A main rule that delegates responsibility for
specifying a security policy for each user's calendars to that user.
•Per-user, per-calendar rules that say which users
can access a calendar and in what way or ways.
The program's administrator might collect all of the run-time files for the
application in the directory /usr/local/cal and its subdirectories, and
organize it as follows:
/usr/local/cal/rules/{acl-rule.0,acl-rule.1,...}
General rules for the application
/usr/local/cal/users/ username
Root directory for calendars owned by
username
/usr/local/cal/users/ username/cal-1/data/*
Per-calendar data files
/usr/local/cal/users/ username/rules/{acl-cal1.0,acl-cal2.0,...}
Per-calendar DACS access control files
/usr/local/cal/users/ username/groups/*
Per-user DACS group lists, one per file
Given these naming conventions:
•to test whether it should perform a particular
operation, the application would call dacscheck, telling it to use the
rules it finds in /usr/local/cal/rules.
•the general rules for the application would
delegate access control decisions for objects with names that match /users/
username/* to access control rules found in the directory
/usr/local/cal/users/ username/rules. These rules would describe which
users, if any, would be permitted to perform a given operation on the
calendar.
•the application would use object names of the
form /users/ username/cal-1?OP=operation as arguments to
dacscheck. The ruleset for cal-1 would determine whether a given
identity is allowed to perform the requested operation on the calendar.
For example, alice (the owner) might be granted access regardless of the value
of the OP argument, while bob might be granted access only if OP=read,
and all others might be denied access. Later, alice might define a set of
users that she names family and change the rule to allow any member of that
group read and update access.
Users' access control rules could themselves be under access control. A command
line, GUI, or web interface would give the administrator and users the ability
to manage rules.
See the EXAMPLES[32] section for example rules.
This is by no means the only way to organize the calendars, and a
delegation-based approach isn't required. The administrator might instead put
all of the rules under a common directory, like /usr/local/cal/rules/acl-
username.0/{acl-cal1.0,acl-cal2.0,...}, or put them closer to the
calendar they are controlling, like /usr/local/cal/users/
username/cal-1/acl-cal1.0.
Instead of testing whether an operation is permitted, rules can be written to
return a constraint string that tells the caller what kind (or kinds) of
access are permitted. The program's output line will include the constraint
string within quotes.
Comparing dacscheck with dacs_acs¶
dacs_acs(8)[8] is the DACS component that is called by Apache (by the DACSmod_auth_dacs[25] module, actually) to perform access control processing on web service requests. Its operation is normally invisible to web services; dacs_acs does all of its work before a web service is even executed or a web page is returned. dacscheck performs a function similar to the -check_only mode of operation of dacs_acs in that it simply returns an access control decision. There are important differences between the two programs, however. dacscheck:•is not a CGI program (though it can be called
from one);
•does not require mod_auth_dacs[25];
•does not use any DACS configuration
files;
•does not directly interact with a web server or
any other DACS programs; and
•runs at the privilege level of the user invoking
it rather than the privilege level of Apache.
While dacscheck uses ordinary DACS access control rules (
dacs.acls(5)[7]), unlike most DACS commands it does not consult
any DACS configuration files. The evaluation environment for access
control rules is similar to that of web service testing, but it is not
identical since there need not be a web server in the picture. Other than the
attributes related to constraints, attributes such as pass_credentials have no
meaning to dacscheck.
Use and configuration of DACS by dacscheck is greatly simplified
because no real federation or jurisdictions are defined; a completely
self-contained environment is created so that a single program or set of
related programs can perform both course-grained and fine-grained access
control tests. No federation or jurisdiction cryptographic keys are used, and
no real DACS credentials are created. Federation and jurisdiction names
are instantiated, but those who write rules will often not need to be aware of
them.
OPTIONS¶
The arguments are processed as they are examined (left-to-right) and their ordering can be significant; for example, values established by the -fh flag may affect options that follow it, such as those that use string interpolation. Exactly one object argument is required. -adminAll identities that follow on the command line are
DACS identities that satisfy the dacs_admin() function. Refer to
the ADMIN_IDENTITY configuration directive in dacs.conf(5)[33] and the
"a" attribute for identities.
-app appname
Specify an application name to be used to construct
default paths (see the -rules and -groups flags).
-context file
Variable definitions for the DACS namespace are
read, one per line, in the format name=value (with optional
quotes around the value). The name must be syntactically valid.
If file is -, the standard input is read. For example, if
file contains the two lines:
then within access control rules ${DACS::FOO} will have the value
"one" and ${DACS::BAZ} will have the value "two".
This flag may be repeated, although the standard input can be read only
once.
-Dname=value
FOO=one BAZ=two
This is equivalent to -varname=value.
-dump
Perform all initializations, display the evaluation
context, and then exit.
-F field_sep
When roles are looked up, use the character
field_sep as the field separator character instead of the default. For
details, refer to the description of the VFS directive in
dacs.conf(5)[34].
Note
Note that only the first occurrence of the character (from left to right) is
treated as the separator character.
-fd domain
Use domain as the domain name for the federation.
It must be syntactically valid.
-fh hostname
Use hostname, a fully-qualified domain name, as
the system's hostname and to derive the federation and jurisdiction names. It
must be syntactically valid.
-fj jurname
Use jurname as the jurisdiction name. It must be
syntactically valid.
-fn fedname
Use fedname as the federation name. It must be
syntactically valid.
-groups group_vfs
By default, dacscheck expects to find DACS
group definitions rooted in the directory dacscheck/groups relative to
DACS_HOME (e.g., /usr/local/dacs/dacscheck/groups), or if -app
appname is given, rooted in the directory dacscheck/
appname/groups relative to DACS_HOME (e.g.,
/usr/local/dacs/dacscheck/myapp/groups) This flag specifies a different
location. It can be an absolute pathname (which will be string interpolated -
see dacs.conf(5)[35]) or a URI in the syntax of the VFS[34]
configuration directive. Examples:
By default, a reference to the group %FOO:people will be mapped to a file named
people.grp within the directory FOO relative to the DACS group
directory.
-h
-groups "[groups]dacs-fs:/local/groups" -groups /home/bob/mygroups
Prints the usage blurb.
-i ident
The given identity is added to the set of identities in
effect during checking. This identity does not necessarily have an account on
the system. If ident is the empty string, however, the flag has no
effect; this is convenient behaviour when the flag is used like -i
${Env::REMOTE_USER:-""}, for example, where REMOTE_USER
may not have been set.
-icgi
If the environment variable REMOTE_USER is set to
a valid simple name or DACS identity, it is added to the set of
identities in effect during checking. If the variable is not set or is
invalid, this flag has no effect.
-icgig
Like the -icgi flag, except any roles associated
with the username will be added.
-il ident
The given identity is "local" and must
correspond to an account on the system; if the -groups flag is in
effect, the account's group membership will be added as roles to
ident.
-ilg ident
Like the -ilg flag, except the account's group
membership will be added as roles to ident regardless of whether the
-groups flag is in effect.
-ieuid
The effective uid of the program is added to the set of
identities. If the -groups flag is in effect, the account's group
membership will be added as roles to ident.
-ieuidg
The effective uid of the program is added to the set of
identities. The account's group membership will be added as roles to
ident regardless of whether the -groups flag is in effect.
-iuid
The real uid of the program is added to the set of
identities. If the -groups flag is in effect, the account's group
membership will be added as roles to ident.
-iuidg
The real uid of the program is added to the set of
identities. The account's group membership will be added as roles to
ident regardless of whether the -groups flag is in effect.
-lg
For each local identity that follows on the command line,
use its Unix group membership to the identity's roles.
-ll log_level
Set the debugging output level to log_level (see
dacs(1)[23]). The default level is warn, and the -v flag bumps
the level to debug or trace.
-name_compare method
Exactly like the NAME_COMPARE[36] directive, set
the default method used to compare DACS names in various contexts to
method, which may be (case-insensitively) case, nocase, or
default.
-q
Be quiet, except for error messages; the outcome will not
be printed to stdout. The -v and -ll flags are independent of
this.
-redirect
If access is denied and the applicable rule calls
redirect()[37] with the BY_SIMPLE_REDIRECT argument, then the specified
URL is printed to stdout. This flag enables the -q flag.
-roles roles_vfs
Roles for each identity that follows on the command line
will be looked up using roles_vfs. It can be an absolute pathname
(which will be string interpolated - see dacs.conf(5)[35]) or a URI in
the syntax of the VFS[34] configuration directive. If any roles are
found, they will be added to any other roles specified for the user (whether
explicitly listed or obtained from Unix group membership). For example, if
/usr/local/myapp/roles contains:
then the command line:
will test access for the identity
{u="auggie",g="admin,users"}.
-rules rule_vfs
bobo:users auggie:admin,users harley:guest
% dacscheck -roles /usr/local/myapp/roles -i auggie /myapp/admin
By default, dacscheck expects to use a ruleset
rooted in the directory dacscheck/acls relative to DACS_HOME (e.g.,
/usr/local/dacs/dacscheck/acls), or if the flag -app
appname is given, rooted in the directory dacscheck/
appname/acls relative to DACS_HOME (e.g.,
/usr/local/dacs/dacscheck/myapp/acls). This flag specifies a different ruleset
to be used. It can be an absolute pathname (which will be string interpolated
- see dacs.conf(5)[35]) or a URI in the syntax of the VFS[34]
configuration directive. Examples:
This flag may be repeated; rulesets will examined in the order in which they are
specified on the command line.
-v
-rules "[acls1]dacs-fs:/local/acls" -rules /usr/local/myrules
Increase the level of debugging output. The flag may be
repeated.
-var name=value
Like the -context flag, this adds a variable
definition to the DACS namespace. The variable
DACS::name will be assigned the string value. The
name must be syntactically valid. This flag may be repeated.
-vfs vfs_uri
Add vfs_uri as a VFS[34] configuration
directive. This flag may be repeated, with later occurrences having a higher
"priority" than earlier ones (just as if they appeared later in
dacs.conf; see dacs.conf(5)[33]).
--
This marks the end of the flag arguments.
EXAMPLES¶
To illustrate how dacscheck might be used with real applications, here are some examples. The first few continue with the hypothetical calendar application described earlier. 1.The file /usr/local/cal/rules/acl-rule.0 might look
like:
This rule redirects requests for a particular user's calendar to that user's
access control rules. It also says that access to the application's binaries
is restricted to authenticated users. The application might issue a command
such as:
which will return an exit status of 0 if REMOTE_USER is granted access to
object; otherwise an exit status of 1 will be returned. A better choice
is to use the command:
which will leave the user unauthenticated if REMOTE_USER is unset or
invalid.
<acl_rule status="enabled"> <services> <delegate url_pattern="/users/alice/*" rule_uri="/usr/local/cal/users/alice/rules/> <delegate url_pattern="/users/bob/*" rule_uri="/usr/local/cal/users/bob/rules/> <service url_pattern="/usr/local/cal/bin/*"/> </services> <rule order="allow,deny"> <allow> user("auth") </allow> </rule> </acl_rule>
% dacscheck -i $REMOTE_USER -rules /usr/local/cal/rules object
% dacscheck -icgi -rules /usr/local/cal/rules object
2.The file /usr/local/cal/users/alice/rules/acl-cal1.0
contains the rule for user alice's "Calendar 1" and might look like:
This rule says that alice is allowed full access to the calendar (there is no
restriction on the operation), but bob only has read access. dacscheck
would be called with /users/alice/cal-1?OP=create,
/users/alice/cal-1?OP=update, or /users/alice/cal-1?OP=read to test for
authorization to perform a create, update, or read operation on the calendar,
respectively.
<acl_rule status="enabled"> <services> <service url_pattern="/users/alice/cal-1/*"/> </services> <rule order="allow,deny"> <precondition> <predicate> user(":alice") </predicate> </precondition> <allow> return(1) </allow> </rule> <rule order="allow,deny"> <precondition> <predicate> ${Args::OP} eq "read" </predicate> </precondition> <allow> user(":bob") </allow> </rule> </acl_rule>
3.If alice defines a DACS group that she calls
family and adds the names julia and auggie to that group, she might modify the
rule above by adding the following:
This rule says that any member of the group alice-family is allowed read and
update access to this calendar. The command:
would report that access is granted.
<rule order="allow,deny"> <precondition> <predicate> ${Args::OP} eq "read" or ${Args::OP} eq "update"</predicate> </precondition> <allow> user("%:alice-family") </allow> </rule>
% dacscheck -i julia /users/alice/cal-1?OP=update
4.The membership of alice's group called alice-family
might be specified in the file /usr/local/cal/users/alice/groups/family
This rule allows only alice to manage the membership of this group, but she is
free modify the rule to allow others to manage her groups.
<acl_rule status="enabled"> <services> <service url_pattern="/users/alice/groups/*"/> </services> <rule order="allow,deny"> <precondition> <predicate> user(":alice") </predicate> </precondition> <allow> return(1) </allow> </rule> </acl_rule>
5.As a final example for this application, alice's rules
might also be under access control:
This rule allows only alice to manage the membership of this group, but she is
free modify the rule to allow others to manage her groups.
<acl_rule status="enabled"> <services> <service url_pattern="/users/alice/groups/*"/> </services> <rule order="allow,deny"> <precondition> <predicate> user(":alice") </predicate> </precondition> <allow> return(1) </allow> </rule> </acl_rule>
6.A popular open source web log analyzer program,
written in Perl, can be invoked as a CGI program. The program includes
security provisions whereby it can restrict access to any user authenticated
by the web server, by username (using REMOTE_USER, as exported by the
web server), or based on the user's IP address (using REMOTE_ADDR). The
approximately 40 lines of code (plus assorted initializations) that implements
this security policy can essentially be replaced by just a few lines of code:
Tip
The DACS distribution includes a Perl module
(/usr/local/dacs/lib/perl/DACScheck.pm) to make dacscheck a little
easier to use. The example above would be written as:
A simple DACS access control rule can be written to duplicate the
program's security functionality (using the user() and from()
predicates, see dacs.exprs(5)[22]), but more sophisticated policies can
be added easily, all without having to modify the Perl program again.
my $exit_value = 0; system "/usr/local/dacs/bin/dacscheck", "-q", "-icgi", "-rules", "/usr/local/webstats/acls", "/webstats"; $exit_value = $? >> 8; # print "dacscheck returned $exit_value for user \"$remote_user\"\n"; if ($exit_value != 0) { # dacscheck denies access; print message and exit exit 1; } # dacscheck grants access, so continue
use DACScheck.pm; dacscheck_rules("/usr/local/webstats/acls"); my $result = dacscheck_cgi("/webstats"); if ($result != 1) { # dacscheck denies access; print message and exit exit 1; } # dacscheck grants access, so continue
DIAGNOSTICS¶
The program exits 0 if access is granted and 1 if access is denied. Any other exit status indicates an error occurred.BUGS¶
A lightweight method of defining DACS groups is needed. Once the internal are stable, this program's functionality will be made available through a C/C++ API, which will permit direct, efficient use by other applications and extensible languages (through perlxs(1), for example). The DACS_ACS argument[38] is not recognized by dacscheck. Identities are not considered when roles are looked up; only the username is matched. Unlike dacs_acs(8)[8], there is no support for automatically setting variables by parsing a message body (a MIME document). It might be possible to create a layer between an application and the underlying system so that dacscheck can be called transparently, or nearly so.SEE ALSO¶
See dacs(1)[23], dacsacl(1)[9], dacs.acls(5)[7], dacs.conf(5)[33], dacs.exprs(5)[22], dacs.groups(5)[24], dacs.java(7)[39]. Rule-based access control[40] DACScheck.pmAUTHOR¶
Distributed Systems Software ( www.dss.ca[41])COPYING¶
Copyright2003-2013 Distributed Systems Software. See the LICENSE[42] file that accompanies the distribution for licensing information.NOTES¶
- 1.
- Perl
- 2.
- PHP
- 3.
- Python
- 4.
- Ruby
- 5.
- Tcl/Tk
- 6.
- geteuid(2)
- 7.
- dacs.acls(5)
- 8.
- dacs_acs(8)
- 9.
- dacsacl(1)
- 10.
- getfacl(1)
- 11.
- setfacl(1)
- 12.
- acl(3)
- 13.
- htpasswd(1)
- 14.
- Using FreeBSD's ACLs
- 15.
- ONLamp.com
- 16.
- POSIX ACLs in Linux
- 17.
- linux.com
- 18.
- Solaris 10 acl(2)
- 19.
- Sun Microsystems
- 20.
- Using Solaris ACLs
- 21.
- Dept. of Computer Science, Duke University
- 22.
- dacs.exprs(5)
- 23.
- dacs(1)
- 24.
- dacs.groups(5)
- 25.
- mod_auth_dacs
- 26.
- dacs(1)
- 27.
- concise syntax
- 28.
- gethostname(3)
- 29.
- gethostbyname(3)
- 30.
- RFC 1738
- 31.
- RFC 3986
- 32.
- EXAMPLES
- 33.
- dacs.conf(5)
- 34.
- dacs.conf(5)
- 35.
- dacs.conf(5)
- 36.
- NAME_COMPARE
- 37.
- redirect()
- 38.
- DACS_ACS argument
- 39.
- dacs.java(7)
- 40.
- Rule-based access control
- 41.
- www.dss.ca
- 42.
- LICENSE
07/17/2013 | DACS 1.4.28b |