All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
@ 2006-07-08 15:04 Noveck, Dave
  2006-07-08 19:27 ` [nfsv4] " Lisa Week
  2006-07-10  8:07 ` Andreas Gruenbacher
  0 siblings, 2 replies; 38+ messages in thread
From: Noveck, Dave @ 2006-07-08 15:04 UTC (permalink / raw)
  To: Sam Falkner; +Cc: Brian Pawlowski, Spencer Shepler, nfs, nfsv4, Lisa Week

Andreas has asked that we consider his proposal when disucssing=20
where to go with regard to ACL in v4.1, at the Montreal IETF
meeting.

I'm wondering whether we should be discussing specific mechanisms.
It would help me if we could have a discussion of what the goals
should be for ACL's in v4.1.  This isn't resally clear to me but
it could be due to my lack of attention to the matter.

Is there anybody who's going to be at Montreal who could lead such
a discussion (I'm thinking 10 minutes worth)?  Or are the goals
already clear in which case somebody can explain things to me=20
offline and we can avoid wasting other people's time.=20

-----Original Message-----
From: Sam Falkner [mailto:Sam.Falkner@Sun.COM]=20
Sent: Saturday, July 08, 2006 10:32 AM
To: Sam Falkner
Cc: nfs@lists.sourceforge.net; Spencer Shepler; Pawlowski, Brian;
nfsv4@ietf.org; Lisa Week
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /
mask,draft-ietf-nfsv4-acls-00 not ready

On Jul 7, 2006, at 9:45 PM, Sam Falkner wrote:

> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>
>> Alternative Proposal
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Instead of adding DENY entries to the ACL for the purpose of masking,

>> attach three optional attributes to each file: owner_class_mask,=20
>> group_class_mask, and other_class_mask. When those attributes are=20
>> present, they define which permissions in an ACE are effective.
>>
>> Each ACE is is restricted by one of these mask attributes in each=20
>> access
>> check:
>>
>>  - OWNER@ entries and entries for the user@domain that currently owns

>> the file
>>    are restricted by owner_class_mask.
>>
>>  - EVERYONE@ entries are restricted by other_class_mask.
>>
>>  - All other entries are restricted by group_class_mask.
>>
>> The effective permissions are computed as the bitwise and (&) of the=20
>> ACE mask and the associated class_mask attribute.
>
> I take it you mean that "the effective access mask bits for ACEs of=20
> type ALLOW"?
>
>> When doing a chmod(2) or when applying a create mask, the=20
>> owner_class_mask, group_class_mask, and other_class_mask attributes=20
>> are modified according to the owner class, group class, and other=20
>> class permissions of the mode parameter as follows:
>>
>>  - The POSIX read permission implies the ACE4_READ_DATA,=20
>> ACE4_READ_ATTRIBUTES, ACE4_READ_ACL, and ACE4_SYNCHRONIZE bitmask=20
>> flags.
>>
>>  - The POSIX write permission implies the ACE4_WRITE_DATA,=20
>> ACE4_APPEND_DATA, ACE4_WRITE_ATTRIBUTES, ACE4_DELETE_CHILD, and=20
>> ACE4_SYNCHRONIZE bitmask flags.
>
> I'm not sure I agree about ACE4_WRITE_ATTRIBUTES, but that's a minor=20
> detail.
>
>>  - The POSIX execute permission implies the ACE4_EXECUTE mask.
>
>> This saves us from bloating ACLs with DENY entries, is more efficient

>> when doing a chmod, and also saves us from destroying permissions in=20
>> user provided DENY entries.
>
> Yes, but at the cost of adding new file attributes...  Don't get me=20
> wrong, I do see merit in this proposal, but I don't know if it'll be=20
> acceptable.
>
>> When an ACL is set, then set all mask attributes to the values=20
>> provided in the same SETATTR operation, and set the remaining mask=20
>> attributes to the union of all ALLOW ACL entries in the ACL that the=20
>> class applies to.
>
> This doesn't take the ordering of the ACL into account; is this your=20
> intention?  So
>
> GROUP@:read_data/write_data:DENY
> GROUP@:read_data/write_data:ALLOW
>
> would result in a group_class_mask of read_data|write_data, right?  =20
> (I'm not saying it's wrong, I'm just making sure I understand.)
>
>> Without any further changes, NFSv4 clients not aware of the three=20
>> optional attributes would not be aware of the restrictions imposed by

>> those masks when querying for the ACL. This would create an=20
>> interoperability problem, and possible security holes. To solve this=20
>> problem, we can extend the GETATTR operation as follows:
>>
>> When a client requests the ACL attribute, check if it also requests=20
>> one or more of the three optional owner_class_mask, group_class_mask,

>> or other_class_mask attributes. If it does, then send the requested=20
>> attributes as they are. If the client requests only the ACL without=20
>> any of the masks, return an ACL with only effective mask flags set,=20
>> and with all other flags removed.
>
> I assume you mean in the ALLOW ACEs only, right?

More thoughts on this model and getattr.  Giving different versions of
the ACL depending on how it's requested leads to problems.  To recap, if
NFSv4.0 client asks for the post-chmod ACL, it'll get the inhibited
version of the ACL.  Tools for modifying an ACL invariably do
read/modify/write.  So NFSv4.0 client reads the stripped down ACL,
modifies it, and writes it back.  At this point, information is lost
-- the stripped down ACL is now the only ACL we have.  This leads to
future environments where some classes of clients inadvertently do bad
things, while others behave more correctly.

The ACL model in draft-ietf-nfsv4-minorversion1-03.txt always shows
every client the entire, correct ACL, every time.

- Sam

>
>> Alternate permissions in the ACL can be enabled by either setting an=20
>> ACL without providing full mask entries, or by setting the=20
>> appropriate
>> bit(s) in
>> the corresponding mask entry or entries.
>
> Yes, I think I understand.
>
>> When comparing POSIX ACLs and the NFSv4 ACL + mask attributes as=20
>> proposed here, one obvious difference is that POSIX ACLs have only=20
>> one mask entry, while I propose three mask entries here. The reason=20
>> for this is that POSIX ACLs can at most grant read, write, and=20
>> execute permissions, and so with POSIX ACLs, the File Owner Class=20
>> permissions are always identical to the permissions granted to the=20
>> owner, and the File Other Class permissions are always identical to=20
>> the permissions granted to others. With NFSv4 ACLs, OWNER@ and=20
>> EVERYONE@ entries may grant additional permissions that go beyond=20
>> what POSIX read, write, and execute can grant, and we need a=20
>> mechanism so that those alternate permissions can be turned off by=20
>> chmod and during file create without destroying the permissions.
>
> Given that EVERYONE@ is not equivalent to the POSIX "other" class, it=20
> could be trimmed down to two.
>
>> I would appreciate if you could take this alternative proposal into=20
>> consideration when deciding how to proceed with NFSv4 Minor Version 1

>> at next week's IETF 66 meeting.
>
> This proposal certainly has its merits.  I have doubts about the=20
> feasibility of adding two or three new file attributes, and new as-=20
> yet-unimplemented semantics, into the minorversion1 draft.  I have=20
> doubts about how this would be implemented on a Windows-based server.
>
> The current design specified in draft-ietf-nfsv4- minorversion1-03.txt

> has implementation experience -- it's released in Solaris 10 update 3,

> a shipping product.  It meets strict POSIX requirements for those=20
> implementations that choose to conform to POSIX.  I believe it's fully

> implementable on a Windows-based server.
>
> I too hope that this can be discussed at IETF 66.
>
> - Sam
>
>>
>>
>> Thanks and best regards,
>> Andreas
>>
>>> REFERENCES
>>>
>>> [1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4-=20
>>> acls-00.txt
>>>
>>> [2] POSIX 1003.1e/2c draft 17 (withdrawn),=20
>>> http://wt.xpilot.org/publications/posix.1e
>>>
>>> [3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix=20
>>> Draft ACLs, draft-ietf-nfsv4-acl-mapping-04.txt
>>>
>>> [4] Spencer Shepler (editor): NFSv4 Minor Version 1,=20
>>> draft-ietf-nfsv4-minorversion1-03.txt
>>
>> --
>> Andreas Gruenbacher <agruen@suse.de>
>> Novell / SUSE Labs
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

^ permalink raw reply	[flat|nested] 38+ messages in thread
* RE: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
@ 2006-07-21 17:16 Yoder, Alan
  2006-07-23 15:45 ` [nfsv4] " Sam Falkner
  0 siblings, 1 reply; 38+ messages in thread
From: Yoder, Alan @ 2006-07-21 17:16 UTC (permalink / raw)
  To: Noveck, Dave, Sam Falkner
  Cc: Lisa Week, nfsv4, J. Bruce Fields, nfs, Spencer Shepler,
	Pawlowski, Brian, Andreas Gruenbacher

A whisper of warning from experience in other
standards bodies (SNIA), where we have things
like this in our spec.  It's dangerous to
place informational algorithms in otherwise=20
normative text, even if they're labeled as=20
informational.  They tend to get enshrined in=20
plugfest procedures, independent certification=20
or test suites, and such, and then they're not=20
really informational any more.  Even the informal
"language" they're written in can get set up
on a pedestal.

I realize this may not be welcome advice, but I'd
advise either keeping these things out of the spec,
or doing the work to formalize them, verify them,=20
and make them normative.  Or both.

Alan

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Alan G. Yoder                                    agy@netapp.com
Technical Staff                          =20
Network Appliance, Inc.                            408-822-6919
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D






> -----Original Message-----
> From: Noveck, Dave=20
> Sent: Friday, July 21, 2006 8:10 AM
> To: Sam Falkner
> Cc: Lisa Week; nfsv4@ietf.org; J. Bruce Fields;=20
> nfs@lists.sourceforge.net; Spencer Shepler; Pawlowski, Brian;=20
> Andreas Gruenbacher
> Subject: RE: [nfsv4] Re: NFSv4 ACL and POSIX interaction /=20
> mask,draft-ietf-nfsv4-acls-00 not ready
>=20
> > The current ACL spec, in the minorversion1 draft and in the=20
> previous =20
> > ACL drafts, rigorously specifies mode/ACL interactions by=20
> specifying =20
> > algorithms.  Bruce had the comment that the spec read as=20
> though the =20
> > algorithm was mandatory.
>=20
> That was my reading.  Was that the intention or not?
>=20
> > Rethinking, it would be preferable to have the ACL specification =20
> > specify requirements, and have the algorithms serve as examples. =20
>=20
> I think the requirements that the algorithms are intended to address,
> would be helpful in understanding, whether the algorithms are=20
> examples or are mandatory.
>=20
> > Or, =20
> > rewrite the sections as requirements, and release=20
> algorithms outside =20
> > the minorversion1 draft, possibly through one or more=20
> informational =20
> > RFCs.  This would shorten the minorversion1 draft, without =20
> > invalidating the existing semantics.
>=20
> I think this would complicate understanding and review.  Even if
> the algorithms are examples and not mandatory, I would imagine
> they would be helpful in understanding the requirements and their
> implications, and if they are helpful, they should be in the spec,
> with an indication that they are illustrative and not mandatory.
>=20
> > We'll try to have an initial draft of the ACL parts of the =20
> > minorversion1 document on August 7.  I'll also add an issue=20
> to nfs4-=20
> > editor.org.
>=20
> Here's a couple of other things I've noted that you might consider
> while working in this area:
>=20
>     There is statement about not using additional mode bits beyond
>     the ones defined but there is a "MUST NOT" addressed to the world
>     in general.  I think the mandate should be for the=20
> server.  It MUST
>     NOT return other bits on GETATTR and MUST return NFS4ERR_INVAL if
>     other bits are set on SETATTR or CREATE/OPEN-create.  The=20
> client is
>     free to use whatever bits he wants.  He is not disobeying the
> protocol
>     but he will get NFS4ERR_INVAL.
>=20
>     I don't see the point of allowing multiple behaviors in=20
> the case in=20
>     which both MODE and ACL are set.  Rather than rell the=20
> client how to
>=20
>     deal with all possible server behaviors, consider mandating the
> order=20
>     in which a SETATTR/CREATE with both MODE and ACL will be processed
> by=20
>     the server.  I think that would make life simpler for everybody.
> The
>     server knows what order he should do these in and the=20
> client knows=20
>     which order the changes will be done in.=20
>=20
> -----Original Message-----
> From: Sam Falkner [mailto:Sam.Falkner@Sun.COM]
> Sent: Thursday, July 20, 2006 6:57 PM
> To: Noveck, Dave
> Cc: Lisa Week; nfsv4@ietf.org; J. Bruce Fields;
> nfs@lists.sourceforge.net; Spencer Shepler; Pawlowski, Brian; Andreas
> Gruenbacher
> Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask,
> draft-ietf-nfsv4-acls-00 not ready
>=20
>=20
> On Jul 18, 2006, at 7:48 PM, Noveck, Dave wrote:
>=20
> > It seems like this is what most users would want.  It=20
> doesn't seem to
> > match what is specified in section 3.16.6.3 of draft-03.  That says
> > the acl is modified when you change the mode.
>=20
> Right -- see below...
>=20
> > What does solaris do if you do a chmod specifying a numeric mode
> > whose value is the same as would be set by doing a chomod +s?  Does
> > that change the ACL?
>=20
> Sorry, I misunderstood your earlier question -- I was testing=20
> against =20
> POSIX-draft ACLs, and not NFSv4 ACLs.  In the case of NFSv4 ACLs (on =20
> ZFS), it does change the ACL, whether you use "+s" or "4xxx".  In my =20
> test, it added a mask ACE for the supplemental user I had added =20
> before, even though the mask didn't really mask anything in this case.
>=20
> As you pointed out, chmod doesn't necessarily have to modify the ACL =20
> to set the setuid bit in the mode, unless the mode requires changes =20
> to the ACL for POSIX conformance.  The mode might require changing =20
> the ACL more times than is obvious, but the ACL specification =20
> shouldn't require unnecessary changes to the ACL...
>=20
> Here's an idea.  It's not an original idea, it's one that Bruce =20
> proposed last April, and unfortunately his comments went unanswered =20
> (mea culpa).
>=20
> The current ACL spec, in the minorversion1 draft and in the previous =20
> ACL drafts, rigorously specifies mode/ACL interactions by specifying =20
> algorithms.  Bruce had the comment that the spec read as though the =20
> algorithm was mandatory.
>=20
> Rethinking, it would be preferable to have the ACL specification =20
> specify requirements, and have the algorithms serve as=20
> examples.  Or, =20
> rewrite the sections as requirements, and release algorithms outside =20
> the minorversion1 draft, possibly through one or more informational =20
> RFCs.  This would shorten the minorversion1 draft, without =20
> invalidating the existing semantics.
>=20
> We'll try to have an initial draft of the ACL parts of the =20
> minorversion1 document on August 7.  I'll also add an issue to nfs4-=20
> editor.org.
>=20
> - Sam
>=20
> (Read on if you're interested in implications.)
>=20
> This would make it possible to craft different algorithms that can =20
> still meet the ACL spec in minorversion1.  Take this example single-=20
> ACE ACL as a starting point:
>=20
> EVERYONE@:read_data/execute::ALLOW
>=20
> and a starting mode of 0555.
>=20
> given a setattr of mode 4555 and no ACL, the new mode MUST become =20
> 4555, and the resulting ACL could legally be any of the following:
>=20
> (current algorithm)
> EVERYONE@:::ALLOW
> OWNER@:write_data/append_data::DENY
> OWNER@:read_data/write_xattr/execute/write_attributes/write_acl/=20
> write_owner::ALLOW
> GROUP@:write_data/append_data::DENY
> GROUP@:read_data/execute::ALLOW
> EVERYONE@:write_data/append_data/write_xattr/write_attributes/=20
> write_acl/write_owner::DENY
> EVERYONE@:read_data/read_xattr/execute/read_attributes/read_acl/=20
> synchronize::ALLOW
>=20
> or
>=20
> (simple ALLOW-only-when-possible algorithm)
> OWNER@:read_data/execute::ALLOW
> GROUP@:read_data/execute::ALLOW
> EVERYONE@:read_data/execute::ALLOW
>=20
> or
>=20
> (unchanged -- this algorithm is smart enough to see that no change =20
> was necessary)
> EVERYONE@:read_data/execute::ALLOW
>=20
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
>=20
>=20

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

^ permalink raw reply	[flat|nested] 38+ messages in thread
* RE: Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
@ 2006-07-21 15:10 Noveck, Dave
  2006-07-21 18:10 ` J. Bruce Fields
  2006-08-04 20:20 ` Sam Falkner
  0 siblings, 2 replies; 38+ messages in thread
From: Noveck, Dave @ 2006-07-21 15:10 UTC (permalink / raw)
  To: Sam Falkner
  Cc: Lisa Week, nfsv4, J. Bruce Fields, nfs, Spencer Shepler,
	Pawlowski, Brian, Andreas Gruenbacher

> The current ACL spec, in the minorversion1 draft and in the previous =20
> ACL drafts, rigorously specifies mode/ACL interactions by specifying =20
> algorithms.  Bruce had the comment that the spec read as though the =20
> algorithm was mandatory.

That was my reading.  Was that the intention or not?

> Rethinking, it would be preferable to have the ACL specification =20
> specify requirements, and have the algorithms serve as examples. =20

I think the requirements that the algorithms are intended to address,
would be helpful in understanding, whether the algorithms are=20
examples or are mandatory.

> Or, =20
> rewrite the sections as requirements, and release algorithms outside =20
> the minorversion1 draft, possibly through one or more informational =20
> RFCs.  This would shorten the minorversion1 draft, without =20
> invalidating the existing semantics.

I think this would complicate understanding and review.  Even if
the algorithms are examples and not mandatory, I would imagine
they would be helpful in understanding the requirements and their
implications, and if they are helpful, they should be in the spec,
with an indication that they are illustrative and not mandatory.

> We'll try to have an initial draft of the ACL parts of the =20
> minorversion1 document on August 7.  I'll also add an issue to nfs4-=20
> editor.org.

Here's a couple of other things I've noted that you might consider
while working in this area:

    There is statement about not using additional mode bits beyond
    the ones defined but there is a "MUST NOT" addressed to the world
    in general.  I think the mandate should be for the server.  It MUST
    NOT return other bits on GETATTR and MUST return NFS4ERR_INVAL if
    other bits are set on SETATTR or CREATE/OPEN-create.  The client is
    free to use whatever bits he wants.  He is not disobeying the
protocol
    but he will get NFS4ERR_INVAL.

    I don't see the point of allowing multiple behaviors in the case in=20
    which both MODE and ACL are set.  Rather than rell the client how to

    deal with all possible server behaviors, consider mandating the
order=20
    in which a SETATTR/CREATE with both MODE and ACL will be processed
by=20
    the server.  I think that would make life simpler for everybody.
The
    server knows what order he should do these in and the client knows=20
    which order the changes will be done in.=20

-----Original Message-----
From: Sam Falkner [mailto:Sam.Falkner@Sun.COM]
Sent: Thursday, July 20, 2006 6:57 PM
To: Noveck, Dave
Cc: Lisa Week; nfsv4@ietf.org; J. Bruce Fields;
nfs@lists.sourceforge.net; Spencer Shepler; Pawlowski, Brian; Andreas
Gruenbacher
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask,
draft-ietf-nfsv4-acls-00 not ready


On Jul 18, 2006, at 7:48 PM, Noveck, Dave wrote:

> It seems like this is what most users would want.  It doesn't seem to
> match what is specified in section 3.16.6.3 of draft-03.  That says
> the acl is modified when you change the mode.

Right -- see below...

> What does solaris do if you do a chmod specifying a numeric mode
> whose value is the same as would be set by doing a chomod +s?  Does
> that change the ACL?

Sorry, I misunderstood your earlier question -- I was testing against =20
POSIX-draft ACLs, and not NFSv4 ACLs.  In the case of NFSv4 ACLs (on =20
ZFS), it does change the ACL, whether you use "+s" or "4xxx".  In my =20
test, it added a mask ACE for the supplemental user I had added =20
before, even though the mask didn't really mask anything in this case.

As you pointed out, chmod doesn't necessarily have to modify the ACL =20
to set the setuid bit in the mode, unless the mode requires changes =20
to the ACL for POSIX conformance.  The mode might require changing =20
the ACL more times than is obvious, but the ACL specification =20
shouldn't require unnecessary changes to the ACL...

Here's an idea.  It's not an original idea, it's one that Bruce =20
proposed last April, and unfortunately his comments went unanswered =20
(mea culpa).

The current ACL spec, in the minorversion1 draft and in the previous =20
ACL drafts, rigorously specifies mode/ACL interactions by specifying =20
algorithms.  Bruce had the comment that the spec read as though the =20
algorithm was mandatory.

Rethinking, it would be preferable to have the ACL specification =20
specify requirements, and have the algorithms serve as examples.  Or, =20
rewrite the sections as requirements, and release algorithms outside =20
the minorversion1 draft, possibly through one or more informational =20
RFCs.  This would shorten the minorversion1 draft, without =20
invalidating the existing semantics.

We'll try to have an initial draft of the ACL parts of the =20
minorversion1 document on August 7.  I'll also add an issue to nfs4-=20
editor.org.

- Sam

(Read on if you're interested in implications.)

This would make it possible to craft different algorithms that can =20
still meet the ACL spec in minorversion1.  Take this example single-=20
ACE ACL as a starting point:

EVERYONE@:read_data/execute::ALLOW

and a starting mode of 0555.

given a setattr of mode 4555 and no ACL, the new mode MUST become =20
4555, and the resulting ACL could legally be any of the following:

(current algorithm)
EVERYONE@:::ALLOW
OWNER@:write_data/append_data::DENY
OWNER@:read_data/write_xattr/execute/write_attributes/write_acl/=20
write_owner::ALLOW
GROUP@:write_data/append_data::DENY
GROUP@:read_data/execute::ALLOW
EVERYONE@:write_data/append_data/write_xattr/write_attributes/=20
write_acl/write_owner::DENY
EVERYONE@:read_data/read_xattr/execute/read_attributes/read_acl/=20
synchronize::ALLOW

or

(simple ALLOW-only-when-possible algorithm)
OWNER@:read_data/execute::ALLOW
GROUP@:read_data/execute::ALLOW
EVERYONE@:read_data/execute::ALLOW

or

(unchanged -- this algorithm is smart enough to see that no change =20
was necessary)
EVERYONE@:read_data/execute::ALLOW

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
@ 2006-07-16 13:10 Noveck, Dave
  2006-07-18 22:08 ` Sam Falkner
  0 siblings, 1 reply; 38+ messages in thread
From: Noveck, Dave @ 2006-07-16 13:10 UTC (permalink / raw)
  To: Sam Falkner, J. Bruce Fields
  Cc: Lisa Week, nfsv4, nfs, Spencer Shepler, Brian Pawlowski,
	Andreas Gruenbacher

What does Solaris do about chmod +s?  Does it modify the ACL? 

-----Original Message-----
From: Sam Falkner [mailto:Sam.Falkner@Sun.COM] 
Sent: Saturday, July 15, 2006 9:56 AM
To: J. Bruce Fields
Cc: Lisa Week; nfsv4@ietf.org; nfs@lists.sourceforge.net; Spencer
Shepler; Pawlowski, Brian; Andreas Gruenbacher
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /
mask,draft-ietf-nfsv4-acls-00 not ready

On Jul 11, 2006, at 9:46 AM, J. Bruce Fields wrote:

> On Tue, Jul 11, 2006 at 08:29:21AM -0400, Sam Falkner wrote:
>> That's not how Solaris works either.  Sorry, I should have explained 
>> it better.  In Solaris using POSIX-draft ACLs, chmod() changes both 
>> the group permissions and the mask, simultaneously.  I now understand

>> why you were hesitant to have chmod affect the group permissions, but

>> having it affect both mask and group solves both problems.
>
> I think you're missing the point of his example.  The point is that a 
> chmod-using application may expect the sequence chmod(600) chmod
> (664) on
> a file with mode 664 to be a no-op.
>
> But if chmod() changes both group and mask bits ("owning group" and 
> "group file class" bits) then this sequence isn't a no-op any more in 
> his example.  It gives GROUP@ write permissions.

Okay, understood.

> So Andreas is trying to ensure the property that any sequence of 
> chmod's that leaves the mode bits the same also leaves the ACL the 
> same.  I agree that that's a nice property.

Perhaps, but I think having chmod unable to set the mode to be a much
more undesirable property, to put it mildly.

> What I'm not convinced of yet is that this is really worth caring 
> about much.  Is this common application behavior?  Have there been 
> complaints about this from people using Solaris's ACLs?

I did some more research, and found that the Solaris chmod() system call
does pretty much what Linux does -- the group permissions of
chmod() affect the mask, not the group permission bits.  Originally, the
chmod command did the chmod() system call, and not much else.

There were many complaints about this.  So many that the chmod command
line was changed to do the chmod() system call, and then, in the
presence of an ACL, fix the permission bits.  In other words, the bug
was fixed.

I have found no complaints about the current Solaris behavior, where
chmod affects group permissions.

- Sam

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 38+ messages in thread
* Re: [nfsv4] Re:  NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
@ 2006-07-14 18:29 Noveck, Dave
  2006-07-14 18:32 ` J. Bruce Fields
  0 siblings, 1 reply; 38+ messages in thread
From: Noveck, Dave @ 2006-07-14 18:29 UTC (permalink / raw)
  To: J. Bruce Fields, nfsv4
  Cc: Sam Falkner, nfs, Spencer Shepler, Pawlowski,  Brian

I think in all the cases you mentioned, we a have situation in 
which the set of attributes you ask for can effect whether you 
get an error or not.  I'm not aware of any case in which you 
will get different values for a single attribute (no error in 
either case) based on whether you are asking for a different 
attribute.  Other than things like asking for an attribute
that doesn't exist will cause an error to be set in rdattr_error,
but that is part of the function of rdattr_error.

-----Original Message-----
From: J. Bruce Fields [mailto:bfields@fieldses.org] 
Sent: Friday, July 14, 2006 2:23 PM
To: nfsv4@ietf.org
Cc: Sam Falkner; Pawlowski, Brian; Spencer Shepler;
nfs@lists.sourceforge.net
Subject: Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction /
mask,draft-ietf-nfsv4-acls-00 not ready


On Fri, Jul 14, 2006 at 01:59:30PM -0400, J. Bruce Fields wrote:
> For a client that doesn't support the new attributes, a server can
apply
> the mask attributes to the ACL before returning it.  I suppose a
> multi-protocol server would do the same for CIFS clients.

By the way, the proposed protocol behavior here is odd:  the server
returns a different ACL depending on whether the client requested any of
the new mask attributes in the same GETATTR.

But I suppose there are other cases (rdattr_error, maybe some migration
cases??) where what we return can depend in strange ways on which
attributes were requested, so maybe it's not totally without precedent?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 38+ messages in thread
* NFSv4 ACL and POSIX interaction / mask
@ 2006-07-03 21:10 Andreas Gruenbacher
  2006-07-07 11:55 ` NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready Andreas Gruenbacher
  2006-07-27  0:59 ` Andreas Gruenbacher
  0 siblings, 2 replies; 38+ messages in thread
From: Andreas Gruenbacher @ 2006-07-03 21:10 UTC (permalink / raw)
  To: nfsv4; +Cc: nfs

Hello,

I have been thinking about the problems of interaction between NFSv4 ACLs and 
POSIX, and particularly about the issue of masking permissions through chmod 
and after creating files or directories.

On a UNIX system that supports NFSv4 ACLs natively, I think we should try to 
accept as wide a range of NFSv4 ACLs as possible, but we must make sure that 
we can preserve POSIX semantics. In particular, this means that ACLs may 
contain ACEs for users other than OWNER@, GROUP@, and EVERYONE@, and that 
chmod(2) must continue to provide the same kinds of guarantees as without 
NFSv4 ACLs.

I am assuming here that NFSv4 ACLs shall be an additional rather than an 
alternate file access control mechanism in the POSIX sense: Alternate file 
access control mechanisms must ``be enabled only by explicit user action, on 
a per-file basis by the file owner or a user with the appropriate 
privilege'', and must ``be disabled for a file after the file permission bits 
are changed for that file with chmod( )'' according to POSIX. In other words, 
newly created files or directories would have alternate file access control 
mechanisms disabled. This would render NFSv4 ACLs essentially useless for 
UNIX processes, because they would almost always be disabled, and would only 
work for remote processes until a POSIX process chmods a file or creates a 
directory, which wouldn't get us very far.

Let's look at chmod(2): the mode specified in chmod(2) defines the permissions 
of three classes of users: owner, group, and other. Each class is assigned a 
set of the READ, WRITE, and EXECUTE permissions. This defines the maximum set 
of permissions that this class has at any moment.

In an NFSv4 ACL, each entry must be in exactly one of the three classes of 
users: OWNER@ is in the owner class, GROUP@ and additional users and groups 
listed in the ACL are in the group class, and EVERYONE@ is in the other 
class.

No ACL entry shall granted permissions that exceed the permissions of its 
class. (Additional permissions in a class could be enabled explicitly, which 
would amount to an alternate file access mechanism, though.)

Note that we must not allow an ACE to be in no class, either: if we did, a 
chmod call with mode 0 would not disable all access, which would conflict 
with POSIX.

Note that this definition is in line with POSIX 1003.1e draft 17 [2], while it 
conflicts with the IETF NFS Version 4 ACLs draft [1], which associates only 
GROUP@ entries with the group file mode permission bits in section 5.1. The 
relevant text of IETF NFS Version 4 ACLs draft [1] is also found in NFSv4 
Minor Version 1 [4].

We want chmod(2) to be non-destructive, so that a chmod to a more restrictive 
mode and back to the original mode will leave the file with the same 
permissions as before the changes.

According to NFS Version 4 ACLs [1], it has been tried to replace the entire 
ACL with an ACL that only grants the permissions specified by the new mode. 
This approach has two drawbacks: first, it is destructive, and additional 
permissions granted are lost in the first chmod. Second, additional 
restrictions (DENY entries) may be lost as well. This is not acceptable, and 
unsurprisingly, users did not favor this approach.

POSIX ACLs have solved the non-destructiveness problem by introducing a mask 
ACL entry: the mask entry applies to all group class entries, and defines an 
upper bound to the permissions those entries may grant. POSIX ACLs only have 
ACL entries that allow permissions, and only specify READ, WRITE, and EXECUTE 
permissions. Therefore, the owner class and other class permissions are the 
permissions granted to the owner and to others, respectively. (Note the 
difference between these others and NFSv4's EVERYONE@ special identifier).

The mask concept is not part of NFSv4 ACLs. Marius A. Eriksen and others have 
proposed to emulate the POSIX ACL mask entry by prepending (with exception of 
OWNER@ and EVERYONE@ ACEs) each ALLOW ACE with a DENY ACE for the same user, 
group, or special identifier as in the ALLOW ACE. The permissions in the DENY 
ACE are set so that the entry denies the permissions not granted by the mask.

Unless we accept a very specific form of NFSv4 ACLs only (which would 
contradict the goal stated at the top of this message, and which would mean 
that interoperability with anything but POSIX ACLs would become difficult), 
there is no easy way to tell DENY entries introduced to emulate the mask from 
DENY entries added by hand. This has two potential consequences:

 - First, if we fail to identify such a mask-emulation DENY entry, we may end 
up inserting another such entry. We might end up doing so repeatedly.

 - Second, we may take a user-provided DENY entry for a mask-emulation DENY 
entry, and clear mask bits from that entry. This would contradict the user's 
intention. So the approach of inserting mask-emulation DENY entries is not 
good enough in general. (Mapping between NFSv4 and POSIX ACLs does not have 
this problem, because POSIX ACLs don't have DENY ACEs.)

In my opinion, there are two possible solutions for this problem: we can (1) 
devise a special kind of NFSv4 ACL entry that we will recognize as mask 
entry, or (2) give the owner/group/other class permission bits higher 
priority than the ACL entries, and only allow permissions that are allowed by 
both the ACEs and their associated classes.

In case (1), we could either keep prepending (almost) each ALLOW entry with an 
associated DENY entry and set a special flag in the DENY entry, or we could 
introduce something like a MASK@ special identifier, add MASK@ entries to the 
ACL in the appropriate places, and add the mask logic to the permission check 
algorithm.

We would need at most three MASK@ entries per ACL, one for each class of 
users: it should be obvious that we need a mask for the group class, which 
contains the GROUP@ entries and all entries for explicitly named users and 
groups. We want to avoid destroying permissions set explicitly for USER@ and 
EVERYONE@ entries after a chmod as well though. We could then use the mask 
mechanism to selectively turn on additional permissions not covered by READ, 
WRITE, and EXECUTE, as a kind of alternate file access control mechanism.

We could keep such extensions local to the server and not expose them over the 
protocol, with the obvious interoperability problems when copying files 
around, or we could make whichever extensions we need part of the NFSv4 
protocol.

Case (2) would be pretty simple to implement, but all permissions that are not 
covered by READ, WRITE, EXECUTE would always be masked (for correctness, even 
for remote clients), and there would be no controlled way to un-mask them.

Thoughts anyone?

Thanks,
Andreas

REFERENCES

[1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4-acls-00.txt

[2] POSIX 1003.1e/2c draft 17 (withdrawn), 
http://wt.xpilot.org/publications/posix.1e

[3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix Draft ACLs, 
draft-ietf-nfsv4-acl-mapping-04.txt

[4] Spencer Shepler (editor): NFSv4 Minor Version 1, 
draft-ietf-nfsv4-minorversion1-03.txt

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

^ permalink raw reply	[flat|nested] 38+ messages in thread
end of thread, other threads:[~2006-08-04 20:20 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-08 15:04 Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready Noveck, Dave
2006-07-08 19:27 ` [nfsv4] " Lisa Week
2006-07-10  8:07 ` Andreas Gruenbacher
2006-07-10 14:24   ` J. Bruce Fields
2006-07-10 15:25     ` Spencer Shepler
2006-07-10 23:48     ` Andreas Gruenbacher
2006-07-11  0:09       ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2006-07-21 17:16 Yoder, Alan
2006-07-23 15:45 ` [nfsv4] " Sam Falkner
2006-07-21 15:10 Noveck, Dave
2006-07-21 18:10 ` J. Bruce Fields
2006-07-23 15:47   ` Sam Falkner
2006-07-25  0:32     ` [nfsv4] " a.gruenbacher
2006-07-25  4:26       ` Sam Falkner
2006-07-25 20:15         ` Andreas Gruenbacher
2006-07-26  4:59           ` Sam Falkner
2006-07-26 13:00             ` [nfsv4] " J. Bruce Fields
2006-08-03 13:46             ` Andreas Gruenbacher
2006-08-04  0:30         ` Andreas Gruenbacher
2006-08-04  1:37           ` Sam Falkner
2006-08-04 10:35             ` Andreas Gruenbacher
2006-08-04 11:19             ` Andreas Gruenbacher
2006-08-04 20:20 ` Sam Falkner
2006-07-16 13:10 Noveck, Dave
2006-07-18 22:08 ` Sam Falkner
2006-07-14 18:29 Noveck, Dave
2006-07-14 18:32 ` J. Bruce Fields
2006-07-03 21:10 NFSv4 ACL and POSIX interaction / mask Andreas Gruenbacher
2006-07-07 11:55 ` NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready Andreas Gruenbacher
2006-07-08  3:45   ` Sam Falkner
2006-07-08  6:51     ` [nfsv4] " Lisa Week
2006-07-09 16:22     ` Andreas Gruenbacher
2006-07-10 13:29       ` Sam Falkner
2006-07-10 14:15         ` [nfsv4] " J. Bruce Fields
2006-07-10 15:32           ` Sam Falkner
2006-07-10 18:57             ` [NFS] " J. Bruce Fields
2006-07-10 22:26               ` [nfsv4] " Sam Falkner
2006-07-10 22:39                 ` J. Bruce Fields
2006-07-10 22:43                   ` J. Bruce Fields
2006-07-11  0:44                   ` Andreas Gruenbacher
2006-07-11  0:15             ` Andreas Gruenbacher
2006-07-11  5:42               ` [nfsv4] " Sam Falkner
2006-07-11  8:05                 ` Andreas Gruenbacher
2006-07-11 12:29                   ` [nfsv4] " Sam Falkner
2006-07-11 13:46                     ` J. Bruce Fields
2006-07-15 13:56                       ` [nfsv4] " Sam Falkner
2006-07-11  0:01           ` Andreas Gruenbacher
2006-07-11  0:28             ` [nfsv4] " J. Bruce Fields
2006-07-11  0:48               ` Andreas Gruenbacher
2006-07-10 22:50         ` Andreas Gruenbacher
2006-07-11  6:17           ` [nfsv4] " Sam Falkner
2006-07-11  8:45             ` Andreas Gruenbacher
2006-07-11 12:44               ` [nfsv4] " Sam Falkner
2006-07-11  6:50       ` Lisa Week
2006-07-11  8:55         ` Andreas Gruenbacher
2006-07-27  0:59 ` Andreas Gruenbacher
2006-07-28  6:32   ` Lisa Week
2006-08-01 10:36     ` [nfsv4] " Andreas Gruenbacher

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.