OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: WI#25 Proposal: Function for comparing file system pathnames

This is a proposal for XACML 2.0 Work Item#25.

25: Function for comparing file system pathnames

   Define a function for specifying and comparing file system
   pathnames used in resource-id.  Possibly new DataType also.


   One of the canonical examples for an access control policy is
   "Subject S is allowed to read files in file system Directory
   D."  An a canonical access request is "Can S read file F?"
   The current XACML Specification has no standard way to handle
   such a policy: there is no standard test for whether a given
   file that the user is trying to access is part of a given
   directory to which the user may have been given access

   One specific use case is trying to model the
   java.io.FilePermission semantics using XACML.  With a
   FilePermission, a Subject can be granted permission to perform
   an action on a file pathname.  If the pathname ends in "/*"
   (where "/" is actually whatever the appropriate file name
   separator character is), then the Subject is granted
   permission to perform the action on all the files and
   directories contained in that directory.  If the pathname ends
   in "/-", then the Subject is granted permission to perform the
   action (recursively) on all files and subdirectories contained
   in that directory. A pathname consisting of the special token
   "<<ALL FILES>>" matches any file.


  1. Is such a function the correct way to handle policies that
     grant or deny access to files?
  2. How are file name separators to be specified?
  3. How is the scope of the template name to be specified
     (i.e. single file, directory and its immediate children,
     directory subtree)?
  4. Should a special syntax be supported to allow substition of
     variable parts of the template file name to be passed as
     Request Context attributes?
  5. Is the matching algorithm correct?  Does this satisfy
     standard syntax for UNIX, Windows, and <other common> file
     systems?  Is the canonicalization sufficient?


  Define a new function with a FunctionId of

  This function provides the ability to match file paths in order
  to determine if one file or subdirectory matches or is in a
  sub-directory of another.  It emulates the
  "java.io.Permission.implies()" method functionality, but may be
  used with arguments that are not specific to the J2SE platform.
  Note that the matching is strictly by name syntax: there is no
  lookup to see if a given file or subdirectory is actually in
  another directory on the platform itself.

  The function takes four arguments of DataType
  http://www.w3.org/2001/XMLSchema#string and returns a result of
  type http://www.w3.org/2001/XMLSchema#boolean.  The result of
  the function is "True" if the file or path specified in the
  third argument matches the fourth argument, using the file name
  separator specified in the first argument and the scope
  specified in the second argument; otherwise, the
  result is "False".


  The arguments to this function must be as follows.  If any
  argument fails to satisfy these requirements, then the function
  evaluates to "Indeterminate".

  1 - an <AttributeValue> containing the file name separator
      character used in the file naming syntax (for example "/"
      or "\").

  2 - an <AttributeValue> describing the scope of the match.
      This argument must be one of three values:
      "file" - the third argument is to be interpreted as a
               single file,
      "directory" - the third argument is to be interpreted as a
               file directory, where all files and directories
               immediately under that directory match,
      "subtree" - the third argument is to be interpreted as a
               file directory, where all files and directory
               recursively under that directory match.

  3 - an <AttributeValue> containing the "template" for the
      match: the file or directory name that the requested name
      must match.

  4 - an <AttributeDesignator> <AttributeSpecifier> indicating
      the requested file or directory name that is to be compared
      to the template in argument 3.

  Matching Algorithm
  The algorithm for matching arguments 3 and 4 is as follows:
  a) Normalize the values for arguments 3 and 4:
     1) Substitutions described below under "String Substitution
        Syntax" are performed for Argument 3.
     2) multiple sequential instances of <separator> are
        collapsed into one.
     3) <separator>..<separator> causes the previous name
        component to be removed: e.g. "x/y/../z" becomes "x/z".
     4) <separator>.</separator> is replaced with <separator>
  b) If argument 3 is not a prefix of argument 4, then the result
     is "false".
  c) If argument 2 is "file":
     - If argument 3 does not match argument 4 by string-equal,
       then the result is "false".  Otherwise the result is
  d) If argument 2 is "directory"
     - If prefix argument 3 is removed from argument 4, and the
       result contains any instance of <separator>, then the
       result is "false".  Otherwise, the result is "true".
  e) If argument 2 is "subtree", the result is "true".

  The following special syntax allows for variables such as "home
  directory" or "installation directory" to be used in the
  template value, names, and resolved based on the environment in
  which the request is evaluated:

  String Substitution Syntax

  If one or more strings of the form "${X.<urn>} occurs in
  argument 3, then they each refer to the value of an Attribute
  in the Request Context that is to be substituted into the
  template file name prior to comparing arguments 3 and 4.  "X"
  must be either "Subject", "Resource", "Action", or
  "Environment", and <urn> must be an XACML Attribute Identifier.
  The indicated Attribute must be of type
  "http://www.w3.org/2001/XMLSchema#string"; and must occur in the
  Request Context as a Subject, Resource, Action, or Environment
  Attribute, respectively.  There can be only one instance of the
  indicated Attribute in the Request Context.  If any of these
  conditions is not satisfied, then the result of the Function is


  In order to specify that the requested file must be an
  immediate child of the Subject's home directory on file system
  "file://x.y.z", the policy would contain the following



  [Actual text and schema changes or additions, referencing line
   numbers in the XACML 1.1 PDF Specification, required to
   express this solution in the 2.0 specification.

   This may be in the form of edits to the source XACML 1.1
   Specification, attached to the e-mail containing the

   Don't bother with this until the SUMMARY indicates there are
   no issues that remain to be resolved, and there is consensus
   on one PROPOSED SOLUTION above.]

Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]