|
List Info
Thread: ACL discussion wrapup
|
|
| ACL discussion wrapup |
|
2006-12-05 18:26:37 |
I may not understand the RETENTION_HOLD attribute
correctly. Is this a single bit?
I'm unsure whether we want to deal with this, but a
Microsoft architect assured me that Bill Gate's mail
has about 100 retention holds on it. The XAM TWG in
SNIA has a 128-bit field reserved for retention
holds, IIRC.
Thanks,
Alan
> -----Original Message-----
> From: J. Bruce Fields [mailto:bfields fieldses.org]
> Sent: Tuesday, December 05, 2006 10:15 AM
> To: nfsv4ietf.org
> Cc: Khan, Saadia; Andreas Gruenbacher; Yoder, Alan
> Subject: Re: [nfsv4] ACL discussion wrapup
>
> On Mon, Nov 13, 2006 at 12:06:03PM -0500, J. Bruce
Fields wrote:
> > OK. I'll wait for any more feedback, then try to
put out an updated
> > version of the proposed automatic inheritance
language next
> week, with
> > the addition of this flag.
>
> It took me longer than expected to get around to
> this--apologies! This
> version adds the DEFAULTED flags and corrects some
minor
> mispellings and
> such.
>
> I think I've incorporated all comments received up to
now. The result
> is a little larger than we had hoped, though I think
the additions are
> necessary. I believe it's still fairly
straightforward, and not too
> difficult to understand or to implement (at least at
the level of the
> protocol; implementing ACL editors that perform
automatic inheritance
> may be more difficult.)
>
> But it's up to the working group whether the additional
complexity is
> worth it....
>
> --b.
>
> dotx.d/head.x | 25 +++++
> nfsv41_middle_fileattributes.xml | 15 +++
> nfsv41_middle_fileattributes_acls.xml | 149
> +++++++++++++++++++++++++++++++++-
> 3 files changed, 187 insertions(+), 2 deletions(-)
>
> diff --git a/dotx.d/head.x b/dotx.d/head.x
> index 064a774..ce4f4d2 100755
> --- a/dotx.d/head.x
> +++ b/dotx.d/head.x
> -266,6 +266,7 const ACE4_INHERIT_ONLY_ACE
> = 0x00000008;
> const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
> const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
> const ACE4_IDENTIFIER_GROUP = 0x00000040;
> +const ACE4_INHERITED_ACE = 0x00000080;
>
>
> /*
> -340,6 +341,26 struct nfsace4 {
> };
>
> /*
> + * ACL flag
> + */
> +typedef uint32_t aclflag4;
> +
> +/*
> + * ACL flag values
> + */
> +const ACL4_AUTO_INHERIT = 0x00000001;
> +const ACL4_PROTECTED = 0x00000002;
> +const ACL4_DEFAULTED = 0x00000004;
> +
> +/*
> + * Version 4.1 Access Control List definition
> + */
> +struct nfsacl41 {
> + aclflag4 flag;
> + nfsace4<> aces;
> +};
> +
> +/*
> * Field definitions for the fattr4_mode attribute
> */
> const MODE4_SUID = 0x800; /* set user id on execution
*/
> -619,6 +640,8 typedef
retention_set4 fattr4_retention_set;
> typedef retention_get4 fattr4_retentevt_get;
> typedef retention_set4 fattr4_retentevt_set;
> typedef uint64_t fattr4_retention_hold;
> +typedef nfsacl41 fattr4_dacl;
> +typedef nfsacl41 fattr4_sacl;
>
> /*
> * Mandatory Attributes
> -701,6 +724,8 const FATTR4_RETENTION_SET = 70;
> const FATTR4_RETENTEVT_GET = 71;
> const FATTR4_RETENTEVT_SET = 72;
> const FATTR4_RETENTION_HOLD = 73;
> +const FATTR4_DACL = 74;
> +const FATTR4_SACL = 75;
>
> typedef opaque attrlist4<>;
>
> diff --git a/nfsv41_middle_fileattributes.xml
> b/nfsv41_middle_fileattributes.xml
> index c157784..4c0b5a3 100755
> --- a/nfsv41_middle_fileattributes.xml
> +++ b/nfsv41_middle_fileattributes.xml
> -175,7 +175,8
> space_used, system, time_access, time_backup,
> time_create, time_metadata, time_modify,
> mounted_on_fileid,
> - layout_type, layout_hint, layout_blksize,
layout_alignment
> + layout_type, layout_hint, layout_blksize,
> layout_alignment,
> + dacl, sacl
> </t>
> </list>
> </t>
> -324,6 +325,12
> Ownership" privilege).
> </c>
>
> +
<c>dacl</c><c>74</c><c>nfsacl4
1<></c><c>R/W</c>
> + <c>
> + Automatically inheritable access control list
used
> + for determining access to filesystem objects.
> + </c>
> +
>
<c>dir_notif_delay</c><c>56</c><c
>nfstime4</c><c>READ</c>
> <c>
> notification delays on directory attributes
> -552,6 +559,12
> on the file object. SETATTR use only.
> </c>
>
> +
<c>sacl</c><c>75</c><c>nfsacl4
1<></c><c>R/W</c>
> + <c>
> + Automatically inheritable access control list
used
> + for logging access to files.
> + </c>
> +
>
<c>send_impl_id</c><c>58</c><c>
;impl_ident4</c><c>WRITE</c>
> <c>
> Client provides server with its implementation
identity
> via SETATTR.
> diff --git a/nfsv41_middle_fileattributes_acls.xml
> b/nfsv41_middle_fileattributes_acls.xml
> index 318b8aa..d4d7650 100755
> --- a/nfsv41_middle_fileattributes_acls.xml
> +++ b/nfsv41_middle_fileattributes_acls.xml
> -582,6 +582,7
> const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG =
0x00000010;
> const ACE4_FAILED_ACCESS_ACE_FLAG =
0x00000020;
> const ACE4_IDENTIFIER_GROUP =
0x00000040;
> + const ACE4_INHERITED_ACE =
0x00000080;
> </artwork>
> </figure>
> A server need not support any
of
> these flags. If the
> -699,7 +700,22
> who value equal to
one
> of the special
> identifiers
outlined in
> <xref
target="acewho" />.
> - </t>
> + </t>
> +
> + <t
hangText="ACE4_INHERITED_ACE">
> + <vspace />
> + Indicates that
this ACE
> is inherited from
> + a parent directory. A
> server that supports
> + automatic inheritance will place
> + this flag on any ACEs
> inherited from the
> + parent directory
when
> creating a new
> + object. Client
> applications will use this
> + to perform automatic inheritance.
> + Clients and servers MUST clear this
> + bit in the acl attribute;
> it may only
> + be used in the dacl and
> sacl attributes.
> + </t>
> +
> </list>
> </t>
> </section>
> -1232,6 +1248,137
> target="setattr" />.
> </t>
> </section>
> +
> + <section title="Automatic
Inheritance">
> + <t>In addition to (or instead of) the acl
> attribute described
> + above, a server may choose to support the
dacl and sacl
> + attributes. These two attributes are identical
> to the acl
> + attribute, except that only ALLOW and DENY aces
> are permitted
> + in the dacl attribute, and only AUDIT and ALARM aces
are
> + permitted in the sacl attribute. Also, the
> sacl and dacl
> + attributes both have an additional flag field
> which applies to
> + the entire sacl or dacl; three flag values are
defined
> + <figure>
> + <artwork>
> + const ACL4_AUTO_INHERIT =
0x00000001;
> + const ACL4_PROTECTED =
0x00000002;
> + const ACL4_DEFAULTED = 0x00000004;
> + </artwork>
> + </figure>
> + and all other bits must be cleared. Finally, the
> + ACE4_INHERITED_ACE flag may be set in the ACEs
> of the sacl
> + or dacl (whereas it must always be cleared in the
acl).
> + </t>
> + <t>
> + Together these features allow a server to
> support automatic
> + inheritance, which we now explain in more detail.
> + </t>
> + <t>
> + Inheritable ACEs are normally inherited by
> child objects only
> + at the time that the child objects are created;
later
> + modifications to inheritable ACEs do not result in
> + modifications to inherited ACEs on descendents.
> + </t>
> + <t>
> + However, the dacl and sacl provide an optional
mechanism
> + which allows a client application to propagate
> changes to
> + inheritable ACEs to an entire directory hierarchy.
> + </t>
> + <t>
> + A server that supports this performs
> inheritance at object
> + creation time in the normal way, but also sets the
> + ACE4_INHERITED_ACE flag on any inherited ACEs
> as they are
> + added to the new object.
> + </t>
> + <t>
> + A client application such as an ACL editor may
> then propagate
> + changes to inheritable ACEs on a directory by
> recursively
> + traversing that directory's descendants and
> modifying each ACL
> + encountered to remove any ACEs with the
> ACE4_INHERITED_ACE flag
> + and to replace them by the new inheritable ACEs
> (also with the
> + ACE4_INHERITED_ACE flag set). It uses the existing
ACE
> + inheritance flags in the obvious way to decide
> which ACEs to
> + propagate. (Note that it may encounter further
> inheritable
> + ACEs when descending the directory heirarchy,
> and that those
> + will also need to be taken into account when
propagating
> + inheritable ACEs to further descendants.)
> + </t>
> + <t>
> + The reach of this propagation may be limited in
> two ways:
> + first, automatic inheritance is not performed from
any
> + directory ACL that has the ACL4_AUTO_INHERIT flag
> + cleared; and second, automatic inheritance
> stops wherever
> + an ACL with the ACL4_PROTECTED flag is set,
preventing
> + modification of that ACL and also (if the ACL is set
on
> + a directory) of the ACL on any of the object's
> descendants.
> + </t>
> + <t>
> + This propagation is performed independently
for the sacl
> + and the dacl attributes; thus the ACL4_AUTO_INHERIT
and
> + ACL4_PROTECTED flags may be independently set
> for the sacl
> + and the dacl, and propagation of one type of
> acl may continue
> + down a heirarchy even where propagation of the
> other acl has
> + stopped.
> + </t>
> + <t>
> + New objects should be created with a dacl and
a
> sacl that
> + both have the ACL4_PROTECTED flag cleared and the
> + ACL4_AUTO_INHERIT flag set to the same value as that
on,
> + respectively, the sacl or dacl of the parent object.
> + </t>
> + <t>
> + Both the dacl and sacl attributes are
optional,
> and a server
> + may support one without supporting the other.
> + </t>
> + <t>
> + A server that supports both the old acl
attribute and
> + one or both of the new dacl or sacl attributes
> must do so
> + in such a way as to keep all three attributes
consistent
> + with each other. Thus the ACEs reported in the
> acl attribute
> + should be the union of the ACEs reported in the dacl
and
> + sacl attributes, except that the
> ACE4_INHERITED_ACE flag must
> + be cleared from the ACEs in the acl. And of course
a
> + client that queries only the acl will be unable
> to determine
> + the values of the sacl or dacl flag fields.
> + </t>
> + <t>
> + When a client performs a SETATTR for the acl
attribute,
> + the server SHOULD set the ACL4_PROTECTED flag to
true on
> + both the sacl and the dacl. By using the acl
attribute,
> + as opposed to the dacl or sacl attributes, the
> client signals
> + that it may not understand automatic
> inheritance, and thus
> + cannot be trusted to set an ACL for which automatic
> + inheritance would make sense.
> + </t>
> + <t>
> + When a client application queries an ACL,
> modifies it, and sets
> + it again, it should leave any ACEs marked with
> + ACE4_INHERITED_ACE unchanged, in their original
> order, at the
> + end of the ACL. If the application is unable
> to do this, it
> + should set the ACL4_PROTECTED flag. This behavior
> + is not enforced by servers, but violations of
> this rule may
> + lead to unexpected results when applications
> perform automatic
> + inheritance.
> + </t>
> + <t>
> + If a server also supports the mode attribute,
> it SHOULD set the
> + mode in such a way that leaves inherited ACEs
> unchanged, in
> + their original order, at the end of the ACL.
> If it is unable
> + to do so, it SHOULD set the ACL4_PROTECTED flag
> on the file's
> + dacl.
> + </t>
> + <t>Finally, in the case where the request
that
> creates a new file
> + or directory does not also set permissions
for
> that file or
> + directory, and there are also no ACEs to
> inherit from the
> + parent's directory, then the server's choice of
> ACL for the new
> + object is implementation-dependent. In this
> case, the server
> + SHOULD set the ACL4_DEFAULTED flag on the ACL
> it chooses for
> + the new object. An application performing automatic
> + inheritance takes the ACL4_DEFAULTED flag as a
> sign that the
> + ACL should be completely replaced by one
> generated using the
> + automatic inheritance rules.
> + </t>
> + </section>
> </section>
> </section>
> </section>
>
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
| ACL discussion wrapup |
|
2006-12-05 18:33:00 |
--- "Yoder, Alan" <agynetapp.com> wrote:
> I may not understand the RETENTION_HOLD attribute
> correctly. Is this a single bit?
I didn't see where Bruce changed RETENTION_HOLD. Anyway,
it is 64 bits long, allowing up to 64 administrative
holds.
>
> I'm unsure whether we want to deal with this, but a
> Microsoft architect assured me that Bill Gate's mail
> has about 100 retention holds on it. The XAM TWG in
> SNIA has a 128-bit field reserved for retention
> holds, IIRC.
>
> Thanks,
>
> Alan
>
> > -----Original Message-----
> > From: J. Bruce Fields [mailto:bfieldsfieldses.org]
> > Sent: Tuesday, December 05, 2006 10:15 AM
> > To: nfsv4ietf.org
> > Cc: Khan, Saadia; Andreas Gruenbacher; Yoder, Alan
> > Subject: Re: [nfsv4] ACL discussion wrapup
> >
> > On Mon, Nov 13, 2006 at 12:06:03PM -0500, J. Bruce
Fields wrote:
> > > OK. I'll wait for any more feedback, then
try to put out an
> updated
> > > version of the proposed automatic inheritance
language next
> > week, with
> > > the addition of this flag.
> >
> > It took me longer than expected to get around to
> > this--apologies! This
> > version adds the DEFAULTED flags and corrects some
minor
> > mispellings and
> > such.
> >
> > I think I've incorporated all comments received up
to now. The
> result
> > is a little larger than we had hoped, though I
think the additions
> are
> > necessary. I believe it's still fairly
straightforward, and not
> too
> > difficult to understand or to implement (at least
at the level of
> the
> > protocol; implementing ACL editors that perform
automatic
> inheritance
> > may be more difficult.)
> >
> > But it's up to the working group whether the
additional complexity
> is
> > worth it....
> >
> > --b.
> >
> > dotx.d/head.x | 25
+++++
> > nfsv41_middle_fileattributes.xml | 15 +++
> > nfsv41_middle_fileattributes_acls.xml | 149
> > +++++++++++++++++++++++++++++++++-
> > 3 files changed, 187 insertions(+), 2
deletions(-)
> >
> > diff --git a/dotx.d/head.x b/dotx.d/head.x
> > index 064a774..ce4f4d2 100755
> > --- a/dotx.d/head.x
> > +++ b/dotx.d/head.x
> > -266,6 +266,7 const ACE4_INHERIT_ONLY_ACE
> > = 0x00000008;
> > const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG =
0x00000010;
> > const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
> > const ACE4_IDENTIFIER_GROUP = 0x00000040;
> > +const ACE4_INHERITED_ACE = 0x00000080;
> >
> >
> > /*
> > -340,6 +341,26 struct nfsace4 {
> > };
> >
> > /*
> > + * ACL flag
> > + */
> > +typedef uint32_t aclflag4;
> > +
> > +/*
> > + * ACL flag values
> > + */
> > +const ACL4_AUTO_INHERIT = 0x00000001;
> > +const ACL4_PROTECTED = 0x00000002;
> > +const ACL4_DEFAULTED = 0x00000004;
> > +
> > +/*
> > + * Version 4.1 Access Control List definition
> > + */
> > +struct nfsacl41 {
> > + aclflag4 flag;
> > + nfsace4<> aces;
> > +};
> > +
> > +/*
> > * Field definitions for the fattr4_mode
attribute
> > */
> > const MODE4_SUID = 0x800; /* set user id on
execution */
> > -619,6 +640,8 typedef
retention_set4 fattr4_retention_set;
> > typedef retention_get4 fattr4_retentevt_get;
> > typedef retention_set4 fattr4_retentevt_set;
> > typedef uint64_t fattr4_retention_hold;
> > +typedef nfsacl41 fattr4_dacl;
> > +typedef nfsacl41 fattr4_sacl;
> >
> > /*
> > * Mandatory Attributes
> > -701,6 +724,8 const FATTR4_RETENTION_SET = 70;
> > const FATTR4_RETENTEVT_GET = 71;
> > const FATTR4_RETENTEVT_SET = 72;
> > const FATTR4_RETENTION_HOLD = 73;
> > +const FATTR4_DACL = 74;
> > +const FATTR4_SACL = 75;
> >
> > typedef opaque attrlist4<>;
> >
> > diff --git a/nfsv41_middle_fileattributes.xml
> > b/nfsv41_middle_fileattributes.xml
> > index c157784..4c0b5a3 100755
> > --- a/nfsv41_middle_fileattributes.xml
> > +++ b/nfsv41_middle_fileattributes.xml
> > -175,7 +175,8
> > space_used, system, time_access,
time_backup,
> > time_create, time_metadata, time_modify,
> > mounted_on_fileid,
> > - layout_type, layout_hint, layout_blksize,
layout_alignment
> > + layout_type, layout_hint, layout_blksize,
> > layout_alignment,
> > + dacl, sacl
> > </t>
> > </list>
> > </t>
> > -324,6 +325,12
> > Ownership" privilege).
> > </c>
> >
> > +
<c>dacl</c><c>74</c><c>nfsacl4
1<></c><c>R/W</c>
> > + <c>
> > + Automatically inheritable access control
list used
> > + for determining access to filesystem objects.
> > + </c>
> > +
> >
<c>dir_notif_delay</c><c>56</c><c
>nfstime4</c><c>READ</c>
> > <c>
> > notification delays on directory attributes
> > -552,6 +559,12
> > on the file object. SETATTR use only.
> > </c>
> >
> > +
<c>sacl</c><c>75</c><c>nfsacl4
1<></c><c>R/W</c>
> > + <c>
> > + Automatically inheritable access control
list used
> > + for logging access to files.
> > + </c>
> > +
> >
<c>send_impl_id</c><c>58</c><c>
;impl_ident4</c><c>WRITE</c>
> > <c>
> > Client provides server with its implementation
identity
> > via SETATTR.
> > diff --git a/nfsv41_middle_fileattributes_acls.xml
> > b/nfsv41_middle_fileattributes_acls.xml
> > index 318b8aa..d4d7650 100755
> > --- a/nfsv41_middle_fileattributes_acls.xml
> > +++ b/nfsv41_middle_fileattributes_acls.xml
> > -582,6 +582,7
> > const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
= 0x00000010;
> > const ACE4_FAILED_ACCESS_ACE_FLAG
= 0x00000020;
> > const ACE4_IDENTIFIER_GROUP
= 0x00000040;
> > + const ACE4_INHERITED_ACE =
0x00000080;
> > </artwork>
> > </figure>
> > A server need not support
any of
> > these flags. If the
> > -699,7 +700,22
> > who value
equal to one
> > of the special
> > identifiers
outlined in
> > <xref
target="acewho" />.
> > - </t>
> > + </t>
> > +
> > + <t
hangText="ACE4_INHERITED_ACE">
> > + <vspace />
> > + Indicates
that this ACE
> > is inherited from
> > + a parent directory. A
> > server that supports
> > + automatic inheritance will place
> > + this flag on any ACEs
> > inherited from the
> > + parent
directory when
> > creating a new
> > + object. Client
> > applications will use this
> > + to perform automatic inheritance.
> > + Clients and servers MUST clear this
> > + bit in the acl attribute;
> > it may only
> > + be used in the dacl and
> > sacl attributes.
> > + </t>
> > +
> > </list>
> > </t>
> > </section>
> > -1232,6 +1248,137
> > target="setattr"
/>.
> > </t>
> > </section>
> > +
> > + <section title="Automatic
Inheritance">
> > + <t>In addition to (or instead of)
the acl
> > attribute described
> > + above, a server may choose to support
the dacl and sacl
> > + attributes. These two attributes are identical
> > to the acl
> > + attribute, except that only ALLOW and DENY aces
> > are permitted
> > + in the dacl attribute, and only AUDIT and ALARM
aces are
> > + permitted in the sacl attribute. Also, the
> > sacl and dacl
> > + attributes both have an additional flag field
> > which applies to
> > + the entire sacl or dacl; three flag values are
defined
> > + <figure>
> > + <artwork>
> > + const ACL4_AUTO_INHERIT =
0x00000001;
> > + const ACL4_PROTECTED =
0x00000002;
> > + const ACL4_DEFAULTED = 0x00000004;
> > + </artwork>
> > + </figure>
> > + and all other bits must be cleared. Finally,
the
> > + ACE4_INHERITED_ACE flag may be set in the ACEs
> > of the sacl
> > + or dacl (whereas it must always be cleared in
the acl).
> > + </t>
> > + <t>
> > + Together these features allow a server
to
> > support automatic
> > + inheritance, which we now explain in more
detail.
> > + </t>
> > + <t>
> > + Inheritable ACEs are normally inherited by
> > child objects only
> > + at the time that the child objects are created;
later
> > + modifications to inheritable ACEs do not result
in
> > + modifications to inherited ACEs on descendents.
> > + </t>
> > + <t>
> > + However, the dacl and sacl provide an optional
mechanism
> > + which allows a client application to propagate
> > changes to
> > + inheritable ACEs to an entire directory
hierarchy.
> > + </t>
> > + <t>
> > + A server that supports this performs
> > inheritance at object
> > + creation time in the normal way, but also sets
the
> > + ACE4_INHERITED_ACE flag on any inherited ACEs
> > as they are
> > + added to the new object.
> > + </t>
> > + <t>
> > + A client application such as an ACL editor may
> > then propagate
> > + changes to inheritable ACEs on a directory by
> > recursively
> > + traversing that directory's descendants and
> > modifying each ACL
> > + encountered to remove any ACEs with the
> > ACE4_INHERITED_ACE flag
> > + and to replace them by the new inheritable ACEs
> > (also with the
> > + ACE4_INHERITED_ACE flag set). It uses the
existing ACE
> > + inheritance flags in the obvious way to decide
> > which ACEs to
> > + propagate. (Note that it may encounter further
> > inheritable
> > + ACEs when descending the directory heirarchy,
> > and that those
> > + will also need to be taken into account when
propagating
> > + inheritable ACEs to further descendants.)
> > + </t>
> > + <t>
> > + The reach of this propagation may be limited in
> > two ways:
> > + first, automatic inheritance is not performed
from any
> > + directory ACL that has the ACL4_AUTO_INHERIT
flag
> > + cleared; and second, automatic inheritance
> > stops wherever
> > + an ACL with the ACL4_PROTECTED flag is set,
preventing
> > + modification of that ACL and also (if the ACL
is set on
> > + a directory) of the ACL on any of the object's
> > descendants.
> > + </t>
> > + <t>
> > + This propagation is performed
independently for the sacl
> > + and the dacl attributes; thus the
ACL4_AUTO_INHERIT and
> > + ACL4_PROTECTED flags may be independently set
> > for the sacl
> > + and the dacl, and propagation of one type of
> > acl may continue
> > + down a heirarchy even where propagation of the
> > other acl has
> > + stopped.
> > + </t>
> > + <t>
> > + New objects should be created with a
dacl and a
> > sacl that
> > + both have the ACL4_PROTECTED flag cleared and
the
> > + ACL4_AUTO_INHERIT flag set to the same value as
that on,
> > + respectively, the sacl or dacl of the parent
object.
> > + </t>
> > + <t>
> > + Both the dacl and sacl attributes are
optional,
> > and a server
> > + may support one without supporting the other.
> > + </t>
> > + <t>
> > + A server that supports both the old acl
attribute and
> > + one or both of the new dacl or sacl attributes
> > must do so
> > + in such a way as to keep all three attributes
consistent
> > + with each other. Thus the ACEs reported in the
> > acl attribute
> > + should be the union of the ACEs reported in the
dacl and
> > + sacl attributes, except that the
> > ACE4_INHERITED_ACE flag must
> > + be cleared from the ACEs in the acl. And of
course a
> > + client that queries only the acl will be unable
> > to determine
> > + the values of the sacl or dacl flag fields.
> > + </t>
> > + <t>
> > + When a client performs a SETATTR for the
acl attribute,
> > + the server SHOULD set the ACL4_PROTECTED flag
to true on
> > + both the sacl and the dacl. By using the acl
attribute,
> > + as opposed to the dacl or sacl attributes, the
> > client signals
> > + that it may not understand automatic
> > inheritance, and thus
> > + cannot be trusted to set an ACL for which
automatic
> > + inheritance would make sense.
> > + </t>
> > + <t>
> > + When a client application queries an ACL,
> > modifies it, and sets
> > + it again, it should leave any ACEs marked with
> > + ACE4_INHERITED_ACE unchanged, in their original
> > order, at the
> > + end of the ACL. If the application is unable
> > to do this, it
> > + should set the ACL4_PROTECTED flag. This
behavior
> > + is not enforced by servers, but violations of
> > this rule may
> > + lead to unexpected results when applications
> > perform automatic
> > + inheritance.
> > + </t>
> > + <t>
> > + If a server also supports the mode attribute,
> > it SHOULD set the
> > + mode in such a way that leaves inherited ACEs
> > unchanged, in
> > + their original order, at the end of the ACL.
> > If it is unable
> > + to do so, it SHOULD set the ACL4_PROTECTED flag
> > on the file's
> > + dacl.
> > + </t>
> > + <t>Finally, in the case where the
request that
> > creates a new file
> > + or directory does not also set
permissions for
> > that file or
> > + directory, and there are also no ACEs to
> > inherit from the
> > + parent's directory, then the server's choice of
> > ACL for the new
> > + object is implementation-dependent. In this
> > case, the server
> > + SHOULD set the ACL4_DEFAULTED flag on the ACL
> > it chooses for
> > + the new object. An application performing
automatic
> > + inheritance takes the ACL4_DEFAULTED flag as a
> > sign that the
> > + ACL should be completely replaced by one
> > generated using the
> > + automatic inheritance rules.
> > + </t>
> > + </section>
> > </section>
> > </section>
> > </section>
> >
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4ietf.org
> https://
www1.ietf.org/mailman/listinfo/nfsv4
>
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
| ACL discussion wrapup |
|
2006-12-05 19:19:20 |
On Tue, Dec 05, 2006 at 10:33:00AM -0800, Mike Eisler wrote:
>
> --- "Yoder, Alan" <agynetapp.com> wrote:
>
> > I may not understand the RETENTION_HOLD attribute
> > correctly. Is this a single bit?
>
> I didn't see where Bruce changed RETENTION_HOLD.
I didn't--he probably just noticed it in the diff context.
By the way, on the new ACE4_WRITE_RETENTION and
ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1 server
required to support
them? (Can a server return NFS4ERR_ATTRNOTSUPP to a setattr
that
attempts to set an ACL using with one of these bits set?)
Do comparable bits exist in Windows ACLs?
Will a 4.0 request for an ACL with one of these bits set see
the bits,
or will they be cleared first?
--b.
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
| ACL discussion wrapup |
|
2006-12-05 19:26:18 |
I am not sure whether Windows has these bits, and I don't
understand
what problem are we trying to solve with these bits.
Mario
-----Original Message-----
From: J. Bruce Fields [mailto:bfieldsfieldses.org]
Sent: Tuesday, December 05, 2006 14:19
To: Mike Eisler
Cc: nfsv4ietf.org
Subject: Re: [nfsv4] ACL discussion wrapup
On Tue, Dec 05, 2006 at 10:33:00AM -0800, Mike Eisler wrote:
>
> --- "Yoder, Alan" <agynetapp.com> wrote:
>
> > I may not understand the RETENTION_HOLD attribute
> > correctly. Is this a single bit?
>
> I didn't see where Bruce changed RETENTION_HOLD.
I didn't--he probably just noticed it in the diff context.
By the way, on the new ACE4_WRITE_RETENTION and
ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1 server
required to support
them? (Can a server return NFS4ERR_ATTRNOTSUPP to a setattr
that
attempts to set an ACL using with one of these bits set?)
Do comparable bits exist in Windows ACLs?
Will a 4.0 request for an ACL with one of these bits set see
the bits,
or will they be cleared first?
--b.
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
| ACL discussion wrapup |
|
2006-12-05 21:37:07 |
--- "J. Bruce Fields" <bfieldsfieldses.org> wrote:
> By the way, on the new ACE4_WRITE_RETENTION and
> ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1 server
required to
> support
> them? (Can a server return NFS4ERR_ATTRNOTSUPP to a
setattr that
No a v4.1 server is not required to support them.
> attempts to set an ACL using with one of these bits
set?)
If an NFSv4.1 implementation supports retention
and ACLs it had better support ACE4_*RETENTION*. Otherwise
the interop matrix gets too complex.
In the server's inode, if it doesn't have separate
permission bits for retention, then the ACE*RETENTION* bits
can be mapped to something else.
>
> Do comparable bits exist in Windows ACLs?
I doubt it.
>
> Will a 4.0 request for an ACL with one of these bits
set see the
> bits,
> or will they be cleared first?
An NFSv4.0 request to SETATTR an ACL with those bits is in
error.
Similarly, and NFSv4.0 response with those bits is in error.
>
> --b.
>
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
| ACL discussion wrapup |
|
2006-12-05 21:41:02 |
--- wurzl_marioemc.com wrote:
> I am not sure whether Windows has these bits, and I
don't understand
> what problem are we trying to solve with these bits.
Last summer, I proposed a very modest set of changes, but
feedback from SNIA was that we needed something more
complex,
hence the current state of Retention. If the consensus is
that
we need something simpler, that's fine with me. Someone make
a
proposal.
>
> Mario
>
>
> -----Original Message-----
> From: J. Bruce Fields [mailto:bfieldsfieldses.org]
> Sent: Tuesday, December 05, 2006 14:19
> By the way, on the new ACE4_WRITE_RETENTION and
> ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1 server
required to
> support
> them? (Can a server return NFS4ERR_ATTRNOTSUPP to a
setattr that
> attempts to set an ACL using with one of these bits
set?)
>
> Do comparable bits exist in Windows ACLs?
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
| ACL discussion wrapup |
|
2006-12-05 22:12:39 |
On Tue, Dec 05, 2006 at 01:37:07PM -0800, Mike Eisler wrote:
> --- "J. Bruce Fields" <bfieldsfieldses.org> wrote:
> > By the way, on the new ACE4_WRITE_RETENTION and
> > ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1
server required to
> > support
> > them? (Can a server return NFS4ERR_ATTRNOTSUPP to
a setattr that
>
> No a v4.1 server is not required to support them.
This contributes somewhat to a problem we already have,
which is that
the ACL is a complex multipart attribute which can be
rejected by a
server for a variety of reasons, and that the only errors
available to
the server to communicate the reason for the rejection are
BADOWNER and
ATTRNOTSUPP. This leaves a user without much guidance as to
how to fix
the problem.
The client could discover the reason for the rejection in
this case by
querying support for the other retention attributes and then
returning
an error. It's not something a client implementator not
interested in
retention support would probably think to do, though....
Or we could advise servers without support to just silently
ignore those
bits.
Maybe a finer-grained aclsupport attribute would also help?
> > attempts to set an ACL using with one of these
bits set?)
>
> If an NFSv4.1 implementation supports retention
> and ACLs it had better support ACE4_*RETENTION*.
Otherwise
> the interop matrix gets too complex.
Makes sense. Could we add language which makes this
explicit?
> > Will a 4.0 request for an ACL with one of these
bits set see the
> > bits,
> > or will they be cleared first?
>
> An NFSv4.0 request to SETATTR an ACL with those bits is
in error.
> Similarly, and NFSv4.0 response with those bits is in
error.
So the server has a choice between returning an error on
such a GETATTR
or returning an ACL with the new bits cleared.
If it does the latter, should it try to do anything special
to avoid the
obvious loss of information on a read-modify-write over
NFSv4.0?
--b.
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|
|
[1-7]
|
|