From: Noveck, Dave (dave.noveck@netapp.com)
Date: 07/29/99-04:03:35 PM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA05D10B88@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: ACLs
Date: Thu, 29 Jul 1999 14:03:35 -0700
>
> Procedure x: GETACL - Get ACL
ACL is currently an attribute with the expectation that GETATTR
and SETATTR with the appropriate mask bits would be used. Is
there any reason to do anything else?
>
> SYNOPSIS
>
> (cfh) -> acl
>
> ARGUMENT
>
>
> /* CURRENT_FH: */
> void;
>
> RESULT
>
> struct ace4 {
> acetype4 type;
> aceflag4 flag;
> acemask4 mask;
> utf8 who;
> ace4 *nextentry;
> };
I'm thinking that nfsacl4 would be defined as ace4<> and that
the nextentry field could not be needed.
>
> struct GETACL4resok {
> aclflag4 flag;
> utf8 owner;
> utf8 group;
> ace4 *aces;
> };
Owner and group are already attributes so you could get those with
a GETATTR together with the ACL, if you wanted to.
>
> union GETACL4res switch (nfsstat4 status) {
> case NFS4_OK:
> GETACL4resok resok4;
> default:
> void;
> };
>
>
> typedef uint32_t acetype4;
> /*
> acetype4 values, others can be added as needed.
> */
> const ACCESS_ALLOWED_ACE_TYPE = 0x0;
> const ACCESS_DENIED_ACE_TYPE = 0x1;
> const SYSTEM_AUDIT_ACE_TYPE = 0x2;
> const SYSTEM_ALARM_ACE_TYPE = 0x3;
>
>
> typedef uint32_t aceflag4;
> /*
> aceflag4, _LOCAL means that the utf8 string is a local identifier
> which cannot be mapped into a global identifier.
> _FAKED means that there is no owner/group that
> can be identified,
> but the utf8 string has an identifier which the
> server can use and
> has no other meaning. _LOCAL should also be set.
I'm not clear what these (_LOCAL and _FAKED) are for.
> FILE_INHERIT_ACE can be placed on a directory
> and indicates that
> this ACE should be added to each new file created.
> DIRECTORY_INHERIT_ACE can be placed on a
> directory and indicates
> that this ACE should be added to each new
> directory created.
> INHERIT_ONLY_ACE can be placed on a directory
> but does not apply
> to the directory, only to newly created
> files/directories as
> specified by the above two flags.
> NO_PROPAGATE_INHERIT_ACE can be placed on a
> directory. Normally
> when a new directory is created and an ACE
> exists on the parent
> directory which is marked DIRECTORY_INHERIT_ACE,
> two ACEs are
> placed on the new directory. One for the
> directory itself and
> one which is an inheritable ACE for newly
> created directories.
> This flag tells the O/S to not place an ACE
> which is inheritable
> by and subdirectories of the created directory.
> SUCCESSFUL_ACCESS_ACE_FLAG and
> FAILED_ACCESS_ACE_FLAG indicate
> for AUDIT and ALARM which state to log the event.
> */
> const ACE4_ID_LOCAL = 0x0001;
> const ACE4_ID_FAKED = 0x0002;
> const FILE_INHERIT_ACE = 0x0004;
> const DIRECTORY_INHERIT_ACE = 0x0008;
> const NO_PROPAGATE_INHERIT_ACE = 0x0010;
> const INHERIT_ONLY_ACE = 0x0020;
> const SUCCESSFUL_ACCESS_ACE_FLAG = 0x0040;
> const FAILED_ACCESS_ACE_FLAG = 0x0080;
All the names should start with ACE4, I think.
>
> typedef uint32_t aclflag4;
> /*
> aclflag4, _LOCAL means that the utf8 string is a local identifier
> which cannot be mapped into a global identifier.
> _FAKED means that there is no owner/group that
> can be identified, but
> the utf8 string has an identifier which the
> server can use, but
> has no other meaning. _LOCAL should be set.
I don't understand the ACL4 versions of (_LOCAL and _FAKED) any
more than I understand the ACE4 versions.
> METHOD_xxxx this the way in which the ACL is
> parsed at the server.
> ORDER means that the first ACE to match both the
> identifier and
> access required is used to determine the access.
> POSIX means that the owner is checked first,
> then the group(s),
> then world. (*** I need a better description here ***)
> */
Why do we need METHOD_xxxx? What does it add? Someone who has a
POSIX acl can, as you point out, easily translate it to METHOD_ORDER
and send it that way. If he gets it from a file and it is in
METHOD_ORDER and he wants to he may have trouble but having two
formats is not going to help him. It is going to be in METHOD_ORDER
format in any case. So why not simplify things and only suppport
METHOD_ORDER, whereupon two flag bits go away (always nice)?
> const ACL4_OWNER_LOCAL = 0x0001;
> const ACL4_OWNER_FAKED = 0x0002;
> const ACL4_GROUP_LOCAL = 0x0004;
> const ACL4_GROUP_FAKED = 0x0008;
> const ACL4_METHOD_ORDER = 0x0010;
> const ACL4_METHOD_POSIX = 0x0020;
> const ACL4_METHOD_UKN1 = 0x0040;
> const ACL4_METHOD_UKN2 = 0x0080;
> **** These should probably be filesystem attributes rather
> then flags ****
> const ACL4_ALLOW_DENY = 0x00010000;
> const ACL4_ALLOW_AUDIT = 0x00020000;
> const ACL4_ALLOW_ALARM = 0x00040000;
I seem to be on anti-aclflag4 rampage but I don't see
ACL4_ALLOW_DENY in any form. I can see ACL4_ALLOW_{AUDIT,ALARM}
as per-fsid attributes.
>
> typedef uint32_t acemask4;
> /*
> acemask4, These masks are based on the NT mask which has
> specific access
> rights and generic rights as well as specialized
> rights which
> may have meaning only to NT.
> */
> const DELETE = 0x00010000;
> const READ_CONTROL = 0x00020000;
> const WRITE_DAC = 0x00040000;
> const WRITE_OWNER = 0x00080000;
> const SYNCHRONIZE = 0x00100000;
> const ACCESS_SYSTEM_SECURITY = 0x01000000;
> const MAXIMUM_ALLOWED = 0x02000000;
I'd like to know what these mean.
>
> const GENERIC_READ = 0x80000000;
> const GENERIC_WRITE = 0x40000000;
> const GENERIC_EXECUTE = 0x20000000;
> const GENERIC_ALL = 0x10000000;
Could we get by with a smaller set (eg. GENERIC_xxxx)?
You mentioned that there were a limited set of bits you
could set through the GUI tools.
>
>
> const FILE_READ_DATA = 0x0001; // file & pipe
> const FILE_LIST_DIRECTORY = 0x0001; // directory
> const FILE_WRITE_DATA = 0x0002; // file & pipe
> const FILE_ADD_FILE = 0x0002; // directory
> const FILE_APPEND_DATA = 0x0004; // file
> const FILE_ADD_SUBDIRECTORY = 0x0004; // directory
> const FILE_READ_EXTENDED_ATTRIBUTES = 0x0008; // file &
> directory
> const FILE_WRITE_EXTENDED_ATTRIBUTES = 0x0010; // file &
> directory
> const FILE_EXECUTE = 0x0020; // file
> const FILE_TRAVERSE = 0x0020; // directory
> const FILE_DELETE_CHILD = 0x0040; // directory
> const FILE_READ_ATTRIBUTES = 0x0080; // all
> const FILE_WRITE_ATTRIBUTES = 0x0100; // all
> const FILE_ALL_ACCESS = (0x000F0000 | SYNCHRONIZE | 0x1FF);
> const FILE_GENERIC_READ =
> (READ_CONTROL|FILE_READ_DATA|FILE_READ_ATTRIBUTES|FILE_READ_EX
> TENDED_ATTRIBUTES|SYNCHRONIZE);
> const FILE_GENERIC_WRITE =
> (READ_CONTROL|FILE_WRITE_DATA|FILE_WRITE_ATTRIBUTES|FILE_WRITE
> _EXTENDED_ATTRIBUTES|FILE_APPEND_DATA|SYNCHRONIZE);
> const FILE_GENERIC_EXECUTE =
> (READ_CONTROL|FILE_READ_ATTRIBUTES|FILE_EXECUTE|SYNCHRONIZE);
>
>
> DESCRIPTION
>
> The GETACL procedure will obtain an ACL for a specific file from
> The server. If no ACL exists a returned value of
> NFSERR4_INVAL should
> be returned.
>
> Sometimes it is not possible for the server to translate
> all identifiers
> to a global identifier. In these cases a local
> identifier is used and
> a flag is set to indicate that the client cannot
> translate the identifier
> to its local set.
>
> There are several special identifiers which need to be
> understood
> universally. They are as follows:
>
> "OWNER@" - The owner of the file.
> "GROUP@" - The group associated with the file.
> "EVERYONE@" - The world.
We might take advantage of Unicode reserved areas to define
something that was even less likely to conflict with other
uses.
> "INTERACTIVE@" - Accessed from an interactive terminal.
> "NETWORK@"- Accessed via the network.
> "DIALUP@" - Accessed as a dialup user to the server.
> "BATCH@" - Accessed from a batch job.
> "ANONYMOUS@" - Accessed without any authentication.
> "AUTHENTICATED@" - Any authenticated user (opposite of
> ANONYMOUS)
> "SERVICE@" - Access from a system service.
For many of these it is unclear how the information in question
could be passed to the nfs server (e.g. whether the accessor is
a batch job or a system service) so there is no way that the nfs
server could act on these entries.
>
>
> It is expected that the GETACL and SETACL routines are
> used in a single
> program to display and modify a files ACL.
I'd say GETATTR and SETATTR.
> A client
> SHOULD display
> all ACE entries in an ACL even though it does not
> understand them. It
> SHOULD also try to preserve any ACEs which it does not
> understand.
Yes.
>
> Translation from ACL4_METHOD_POSIX to ACL4_METHOD_ORDER
> is possible, but
> converting in the other direction is not one to one. (no
> solution yet).
What to you mean "yet"? I think is a problem that will never have
a solution. The space of ORDER ACL's (with denial entries) is just
bigger.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:24 AM Z CST