[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. MOTIVATING USE-CASE AND REQUIREMENT 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 permission. 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. SUMMARY OF OPEN ISSUES 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? PROPOSED SOLUTION Define a new function with a FunctionId of "urn:oasis:names:tc:xacml:1.0:function:file-path-match". 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". Arguments --------- 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 "true". 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 Indeterminate. Example ------- 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 predicate: <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:file-path-match"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string" >/</AttributeValue> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string" >directory</AttributeValue> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string" >file://x.y.z/${Subject.urn:something:names:attributes:homeDirectory}/public</AttributeValue> <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </Apply> DETAILED SOLUTION [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 Proposal. 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]