> 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:[email protected]]
Sent: Thursday, July 20, 2006 6:57 PM
To: Noveck, Dave
Cc: Lisa Week; [email protected]; J. Bruce Fields;
[email protected]; 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
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
On Jul 24, 2006, at 6:32 PM, [email protected] wrote:
> On Sunday, 23. July 2006 17:47, Sam Falkner wrote:
>> On Jul 21, 2006, at 12:10 PM, J. Bruce Fields wrote:
>>> On Fri, Jul 21, 2006 at 11:10:04AM -0400, Noveck, Dave wrote:
>>>>> Rethinking, it would be preferable to have the ACL specification
>>>>> specify requirements, and have the algorithms serve as examples.
>>>>
>>>> I think the requirements that the algorithms are intended to
>>>> address,
>>>> would be helpful in understanding, whether the algorithms are
>>>> examples or are mandatory.
>>>
>>> Yes. My point wasn't necessarily that they should not be mandatory
>>> (though I think they probably shouldn't be--I'm not yet convinced
>>> they're actually correct), but that we need clarified whether
>>> they're
>>> mandatory or not, and what requirements they're meant to meet,
>>> before we can evaluate them properly.
>>
>> If you have any concerns about their correctness, please let me
>> know. As of now, there has not been a single example showing a flaw
>> in them.
>
> There are several flaws, but the lack of clarity on what the
> algorithms are
> meant to achieve makes this somewhat difficult to see.
>
>> I realize this is difficult without having the requirements listed
>> explicitly -- this will be remedied very soon.
>
> Looking at draft-ietf-nfsv4-minorversion1-04.txt, I disagree with
> secion
> 5.4.1. "Discussion of EVERYONE@".
The fact that you disagree with it is not a flaw. That section is
very simple -- it says that EVERYONE@ means "everyone".
If you are arguing that EVERYONE@ ACEs should be affected by the
POSIX "other" class upon chmod(), then that's not in disagreement
with 5.4.1.
> Section 5.5. "Mode Attribute" claims that
> MODE4_RGRP, MODE4_WGRP, MODE4_XGRP apply to the principals
> identified in the
> owner_group attribute, while it's really the File Group Class
> according to
> POSIX.
Since when does POSIX define NFSv4? RFC 3530 is the current
authority on NFSv4, and it says that the mode attribute is based upon
the UNIX mode -- seems sensible to me.
> From that pretty much follows that the algorithm defined in Section
> 5.6.1. is not POSIX compliant: the File Group Class permissions
> must be a
> superset of the permissions of the permissions granted to all ACEs
> for a who
> other than OWNER@ and EVERYONE@, and the 5.6.1. algorithm does not
> guarantee
> this.
You are arguing that NFSv4 should define MODE4_RGRP, MODE4_WGRP, and
MODE4_XGRP to be something other than the UNIX mode bits. The fact
that you argue this does not make it a requirement. As stated above,
RFC 3530 defines these bits as reflecting the mode.
ACL is not a required attribute in NFSv4. If we adopted your
proposal, a client that supported mode but not ACL would be unable to
set the mode of a file.
But let's pretend that all NFSv4 clients do support the ACL
attribute. Having the chmod command unable to set the mode was a
source of many customer complaints when that was the behavior in
Solaris (http://xrl.us/pd7c and http://xrl.us/pd7b are just two
examples of bugs). The Solaris chmod command was fixed to alter the
POSIX-draft ACL (in file systems that support POSIX-draft ACLs), so
that chmod was actually able to change the mode. Since making this
change to chmod, complaints have stopped.
So, if we were to do as your proposed design says, and have
MODE4_RGRP, etc., not reflect the mode, then once again, we would
have to modify the chmod command to do more than the chmod() system
call. This is madness.
Or, we could simply have MODE4_RGRP, etc., reflect the mode of the file.
> Algorithm 5.6.3. is at least problematic because it enforces
> implementing
> masking of permissions using DENY ACEs, while an alternative design
> exists
> that achieves the same effects without the disadvantages of those
> DENY ACEs.
That alternative introduces a new file attribute, which causes
problems for NFSv4.0, and for Windows servers.
> The paragraphs below "3. To conform with POSIX" is lossy, even with
> the
> six-entry ACL that "2. If there are at least six ACEs" would
> create, which is
> a very unfavorable property.
No, it is not lossy with the six-entry ACE in "2. ...". That's
because the six-entry ACE in "2." will be adjusted in the "3."
immediately following "2.".
In general, the algorithm can be lossy, when modes such as 077 are
assigned to files having ACLs that grant read/write/execute to
supplemental groups.
> It also does not cover the case where the owner
> is granted permissions from EVERYONE@ ACEs, or where users or
> groups matching
> user@domain or group@domain are granted permissions from EVERYONE@
> ACEs.
EVERYONE@ ACEs are covered. Re-read the algorithm.
> I can't see a compelling reason for requiring the exact six-entry
> ACL as
> specified in "2. If there are at least six ACEs".
The goal of that step is to re-use the final six ACEs if possible, so
that successive changes to the mode don't cause a growing ACL.
> Finally, I have argued why it is wrong to have a mode SETATTR write
> through to
> USER@, GROUP@, and EVERYONE@ ACEs.
To not do so leaves you in the situation where a client that supports
the mode attribute and not the ACL attribute cannot set the mode.
* * *
So, once again, no real flaw has been pointed out in the existing
specification.
> I have described a lot of aspects to the problem both here on this
> list and in
> a design document, available at
> http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-
> posix-00.html, and I
> would very much appreciate if you could comment on which parts you
> disagree
> with and why, in order so that we can come to a conclusion on what
> we want to
> achieve. I am convinced that once we agree on the basic framework
> we operate
> within, how to do so will become a lot more obvious.
A more detailed analysis is forthcoming; for now, here's an early
summary of objections.
Your design tries very hard to preserve information in ACLs while
retaining POSIX compliance at chmod() and create-with-mode time. It
does this by introducing a new file attribute. The file attribute
will not be understood by an NFSv4.0 client or server. Thus, when an
NFSv4.0 client manipulates the ACL via read/modify/write, it has just
destroyed the information you tried to preserve within the ACL.
Nor will the new file mask attribute be implemented natively on a
Windows file system. Thus, Windows servers will have significantly
different access semantics for NFS clients than for users accessing
the file system locally.
An NFS server giving different answers for "what is the ACL",
depending on who's asking or how are they asking, will lead to
confusion and frustration for end users.
One thing I'm very curious about is what you would expect an NFS
client that supports the new access-mask-file-attribute to do with a
server that does not support this attribute. I cannot see a
satisfactory outcome, but I won't call this a flaw yet, since your
design is still being worked on.
Finally, your design also specifies that the mode attribute not
reflect the file mode. It makes it impossible for a non-ACL-aware
client to reliably get or set the owner/group/other permissions on a
file. Even on an ACL-aware client, it demands that end user
utilities understand and support NFSv4 ACLs in order to set the mode
of a file.
It also advocates umask behavior that is not legal within POSIX, but
that is outside the scope of NFS.
- Sam
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tuesday, 25. July 2006 06:26, Sam Falkner wrote:
> On Jul 24, 2006, at 6:32 PM, [email protected] wrote:
> > Looking at draft-ietf-nfsv4-minorversion1-04.txt, I disagree with
> > secion
> > 5.4.1. "Discussion of EVERYONE@".
>
> The fact that you disagree with it is not a flaw. That section is
> very simple -- it says that EVERYONE@ means "everyone".
>
> If you are arguing that EVERYONE@ ACEs should be affected by the
> POSIX "other" class upon chmod(), then that's not in disagreement
> with 5.4.1.
Alright, fine then.
> > Section 5.5. "Mode Attribute" claims that
> > MODE4_RGRP, MODE4_WGRP, MODE4_XGRP apply to the principals
> > identified in the
> > owner_group attribute, while it's really the File Group Class
> > according to POSIX.
>
> Since when does POSIX define NFSv4? RFC 3530 is the current
> authority on NFSv4, and it says that the mode attribute is based upon
> the UNIX mode -- seems sensible to me.
POSIX does not define NFSv4. The mode attribute directly maps to the POSIX
file mode though, and I assume we have agreement on that.
My argument is that there is a conceptual difference between the MODE4_RGRP,
MODE4_WGRP, MODE4_XGRP permission bits (which map to the POSIX File Group
Class) and the owner_group permissions: this has to do with the
classification of ACEs, and with the file access control mechanisms that
POSIX allows.
RFC3530 does not go very deeply into the interactions between the mode
attribute and POSIX. In Section 5.11.5. "Mode Attribute" RFC2530 defines that
the MODE4_RGRP, MODE4_WGRP, MODE4_XGRP bits apply to the principals
identified in the owner_group attribute. This is a less general definition
than how POSIX defines File Permission Bits, which are part of the file mode:
[] File Permission Bits
[]
[] Information about a file that is used, along with other information, to
[] determine whether a process has read, write, or execute/search permission
[] to a file. The bits are divided into three parts: owner, group, and other.
[] Each part is used with the corresponding file class of processes. These
[] bits are contained in the file mode.
On POSIX systems that only support the POSIX File Permission Bits and no other
file access control mechanisms, both definitions amount to the same. On
systems that implement additional file access control mechanisms, the File
Group Class permission bits are no longer necessarily identical with the
permissions granted to the owning group: the definition of Additional File
Access Control Mechanisms allows further restrictions to be imposed. In other
words, the owning group may only be granted a subset of the File Group Class
permissions.
You are arguing that users have been confused by this definition, and that
changing the File Group Class permissions (=changing the MODE4_RGRP,
MODE4_WGRP, MODE4_XGRP bits in the mode attribute) should automatically also
change the owner_group permissions, and that this is how chmod behaves with
POSIX ACLs on Solaris (and which differs from how implementations of POSIX
1003.1e draft 17 (withdrawn) are supposed to behave). In Section 4.6. "Mode
Changes and the OWNER@, GROUP@, and EVERYONE@ ACEs" of
http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-posix-00.html I am
pointing out two reasons why the Solaris behavior is a really bad idea. (Note
that these problems may well be the reason why Solaris appears to behave
differently at the system call level.)
I would be sorry if you persisted in implementing the current Solaris chmod
behavior in NFSv4, but in case you really do, this hack still does not belong
into the NFSv4.1 specification, and I would in that case much prefer if you
could just break Solaris, and not everybody else as well.
> > From that pretty much follows that the algorithm defined in Section
> > 5.6.1. is not POSIX compliant: the File Group Class permissions
> > must be a superset of the permissions of the permissions granted to all
> > ACEs for a who other than OWNER@ and EVERYONE@, and the 5.6.1. algorithm
> > does not guarantee this.
>
> You are arguing that NFSv4 should define MODE4_RGRP, MODE4_WGRP, and
> MODE4_XGRP to be something other than the UNIX mode bits.
No, this is a misunderstanding. I am arguing that the NFSv4 mode attribute map
to the POSIX mode bits, in the precise semantics which POSIX assigns to these
bits.
> The fact that you argue this does not make it a requirement. As stated
> above, RFC 3530 defines these bits as reflecting the mode.
I have above argued within which limits the definition in RFC3530 is correct
with respect to POSIX, and that this definition is not general enough as soon
as ACLs, in the form of additional file access control mechanisms, are used
on POSIX compliant systems.
> ACL is not a required attribute in NFSv4. If we adopted your
> proposal, a client that supported mode but not ACL would be unable to
> set the mode of a file.
Not at all. Maybe you can explain what makes you think so. An application can
set the mode with a mode SETATTR at any time, etc.
> But let's pretend that all NFSv4 clients do support the ACL
> attribute. Having the chmod command unable to set the mode was a
> source of many customer complaints when that was the behavior in
> Solaris (http://xrl.us/pd7c and http://xrl.us/pd7b are just two
> examples of bugs). The Solaris chmod command was fixed to alter the
> POSIX-draft ACL (in file systems that support POSIX-draft ACLs), so
> that chmod was actually able to change the mode. Since making this
> change to chmod, complaints have stopped.
Maybe nobody explained to users how to properly use ACLs to prevent this from
happening? The behavior of Solaris chmod(1) is a potential security hole,
although a small one only.
> So, if we were to do as your proposed design says, and have
> MODE4_RGRP, etc., not reflect the mode, then once again, we would
> have to modify the chmod command to do more than the chmod() system
> call. This is madness.
This is not what I am proposing at all.
> Or, we could simply have MODE4_RGRP, etc., reflect the mode of the file.
This *is* what I am proposing. A mode SETATTR also affects which permissions
are effective in the ACL and which must be disabled, though. Both proposals
disable permissions, but they do so using different mechanisms: your proposal
introduces DENY ACEs spread throughout the ACL. My proposal sets masks, which
are only applied in the access check algorithm. I argue that simply updating
the masks is a much nicer way of achieving the same effect, and that it
avoids the problems inherent to those DENY ACEs.
> > Algorithm 5.6.3. is at least problematic because it enforces implementing
> > masking of permissions using DENY ACEs, while an alternative design exists
> > that achieves the same effects without the disadvantages of those
> > DENY ACEs.
>
> That alternative introduces a new file attribute, which causes
> problems for NFSv4.0, and for Windows servers.
That's not true. There are several ways how we can deal with clients that do
not understand masks:
(1) we can apply the masks before exposing the ACL to such clients, or
(2) we can introduce DENY ACEs where necessary, as per your proposal.
With (2), we are back to the problems with DENY ACEs: clients which reorder
ACEs as (at least some versions of) Windows do will cause havoc. *But* we
will never run into any such effects with clients that *do* understand masks,
we don't have to bloat ACLs all the time,
On the other hand, with (1), an ACL read-modify-write cycle will potentially
lose some information, but the huge benefit is that the ACLs that clients
will see will actually make some sense to them, instead of being littered
with DENY ACEs that nobody will know how to deal with. Of course clients that
understand masks will be fine as well.
With both mechanisms, knocking the right mask bits in place in the ACL will
cause these bits to become effective (provided that other ACEs don't deny
them earlier in the ACL).
> > The paragraphs below "3. To conform with POSIX" is lossy, even with the
> > six-entry ACL that "2. If there are at least six ACEs" would
> > create, which is a very unfavorable property.
>
> No, it is not lossy with the six-entry ACE in "2. ...". That's
> because the six-entry ACE in "2." will be adjusted in the "3."
> immediately following "2.".
>
> In general, the algorithm can be lossy, when modes such as 077 are
> assigned to files having ACLs that grant read/write/execute to
> supplemental groups.
Exactly, the algorithm is lossy with supplemental groups. I misread that "3.
To conform with POSIX" only applies to explicit groups. My point still stands
though.
Where does the algorithm deal with explicit users?
Masks are not lossy per se, they will only become lossy when talking to
clients that don't understand masks (and in those cases, the effects will
never be worse than with DENY ACEs).
> > It also does not cover the case where the owner
> > is granted permissions from EVERYONE@ ACEs, or where users or
> > groups matching
> > user@domain or group@domain are granted permissions from EVERYONE@
> > ACEs.
>
> EVERYONE@ ACEs are covered. Re-read the algorithm.
Ah, I see now, "3. To conform with POSIX" only refers to explicit groups.
> > I can't see a compelling reason for requiring the exact six-entry
> > ACL as specified in "2. If there are at least six ACEs".
>
> The goal of that step is to re-use the final six ACEs if possible, so
> that successive changes to the mode don't cause a growing ACL.
There is no reason for requiring this exact six-entry ACL other that that the
algorithm you have chosen relies on this exact form. Other algorithms may be
just fine with something completely different. I don't think that NFSv4.1
should limit implementations in ways like this.
> > Finally, I have argued why it is wrong to have a mode SETATTR write
> > through to USER@, GROUP@, and EVERYONE@ ACEs.
>
> To not do so leaves you in the situation where a client that supports
> the mode attribute and not the ACL attribute cannot set the mode.
Not true. What makes you think so?
Andreas
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
On Jul 25, 2006, at 2:15 PM, Andreas Gruenbacher wrote:
> On Tuesday, 25. July 2006 06:26, Sam Falkner wrote:
>> On Jul 24, 2006, at 6:32 PM, [email protected] wrote:
>>> Looking at draft-ietf-nfsv4-minorversion1-04.txt, I disagree with
>>> secion
>>> 5.4.1. "Discussion of EVERYONE@".
>>
>> The fact that you disagree with it is not a flaw. That section is
>> very simple -- it says that EVERYONE@ means "everyone".
>>
>> If you are arguing that EVERYONE@ ACEs should be affected by the
>> POSIX "other" class upon chmod(), then that's not in disagreement
>> with 5.4.1.
>
> Alright, fine then.
>
>>> Section 5.5. "Mode Attribute" claims that
>>> MODE4_RGRP, MODE4_WGRP, MODE4_XGRP apply to the principals
>>> identified in the
>>> owner_group attribute, while it's really the File Group Class
>>> according to POSIX.
>>
>> Since when does POSIX define NFSv4? RFC 3530 is the current
>> authority on NFSv4, and it says that the mode attribute is based upon
>> the UNIX mode -- seems sensible to me.
>
> POSIX does not define NFSv4. The mode attribute directly maps to
> the POSIX
> file mode though, and I assume we have agreement on that.
>
> My argument is that there is a conceptual difference between the
> MODE4_RGRP,
> MODE4_WGRP, MODE4_XGRP permission bits (which map to the POSIX File
> Group
> Class) and the owner_group permissions: this has to do with the
> classification of ACEs, and with the file access control mechanisms
> that
> POSIX allows.
>
> RFC3530 does not go very deeply into the interactions between the mode
> attribute and POSIX. In Section 5.11.5. "Mode Attribute" RFC2530
> defines that
> the MODE4_RGRP, MODE4_WGRP, MODE4_XGRP bits apply to the principals
> identified in the owner_group attribute. This is a less general
> definition
> than how POSIX defines File Permission Bits, which are part of the
> file mode:
>
> [] File Permission Bits
> []
> [] Information about a file that is used, along with other
> information, to
> [] determine whether a process has read, write, or execute/search
> permission
> [] to a file. The bits are divided into three parts: owner, group,
> and other.
> [] Each part is used with the corresponding file class of
> processes. These
> [] bits are contained in the file mode.
>
> On POSIX systems that only support the POSIX File Permission Bits
> and no other
> file access control mechanisms, both definitions amount to the
> same. On
> systems that implement additional file access control mechanisms,
> the File
> Group Class permission bits are no longer necessarily identical
> with the
> permissions granted to the owning group: the definition of
> Additional File
> Access Control Mechanisms allows further restrictions to be
> imposed. In other
> words, the owning group may only be granted a subset of the File
> Group Class
> permissions.
You can implement such a design and be POSIX compliant. You can also
implement a design where setting only the mode allows full control of
read/write/execute for owner/owner_group/other, and be POSIX
compliant. With both Alternate and Additional File Access Controls
available, there many ways to implement an NFSv4 ACL model and be
POSIX compliant.
Even though your design is not yet complete, I believe that it will
be POSIX compliant. That's not the problem. A major problem with
your design is that NFSv4 clients that do not support the optional
ACL attribute will be unable to control read/write/execute for owner/
owner_group/other.
> You are arguing that users have been confused by this definition,
> and that
> changing the File Group Class permissions (=changing the MODE4_RGRP,
> MODE4_WGRP, MODE4_XGRP bits in the mode attribute) should
> automatically also
> change the owner_group permissions, and that this is how chmod
> behaves with
> POSIX ACLs on Solaris (and which differs from how implementations
> of POSIX
> 1003.1e draft 17 (withdrawn) are supposed to behave). In Section
> 4.6. "Mode
> Changes and the OWNER@, GROUP@, and EVERYONE@ ACEs" of
> http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-
> posix-00.html I am
> pointing out two reasons why the Solaris behavior is a really bad
> idea. (Note
> that these problems may well be the reason why Solaris appears to
> behave
> differently at the system call level.)
You do indeed point out two reasons in your Section 4.6. We have
solid data from implementation experience and customer support calls
that Section 4.6 reaches the wrong conclusion. End users have
complained about the behavior of the defunct 1003.1e draft 17. When
the chmod command was changed to end-run around this behavior, there
were no more complaints about the chmod command.
Whether this is a security hole is a matter of opinion. I would be
interested in how many are of the opinion that an explicit chmod to
mode 644 always giving read access to owner_group is a security hole;
and even if it is, that it is necessary to confuse and annoy end
users to the point that they generate service calls and demand a fix.
> I would be sorry if you persisted in implementing the current
> Solaris chmod
> behavior in NFSv4, but in case you really do, this hack still does
> not belong
> into the NFSv4.1 specification, and I would in that case much
> prefer if you
> could just break Solaris, and not everybody else as well.
>
>>> From that pretty much follows that the algorithm defined in Section
>>> 5.6.1. is not POSIX compliant: the File Group Class permissions
>>> must be a superset of the permissions of the permissions granted
>>> to all
>>> ACEs for a who other than OWNER@ and EVERYONE@, and the 5.6.1.
>>> algorithm
>>> does not guarantee this.
>>
>> You are arguing that NFSv4 should define MODE4_RGRP, MODE4_WGRP, and
>> MODE4_XGRP to be something other than the UNIX mode bits.
In the back-and-forth below, substitute "mode" with "ability to
reliably control read/write/execute for owner/owner_group/other".
> No, this is a misunderstanding. I am arguing that the NFSv4 mode
> attribute map
> to the POSIX mode bits, in the precise semantics which POSIX
> assigns to these
> bits.
>
>> The fact that you argue this does not make it a requirement. As
>> stated
>> above, RFC 3530 defines these bits as reflecting the mode.
>
> I have above argued within which limits the definition in RFC3530
> is correct
> with respect to POSIX, and that this definition is not general
> enough as soon
> as ACLs, in the form of additional file access control mechanisms,
> are used
> on POSIX compliant systems.
>
>> ACL is not a required attribute in NFSv4. If we adopted your
>> proposal, a client that supported mode but not ACL would be unable to
>> set the mode of a file.
>
> Not at all. Maybe you can explain what makes you think so. An
> application can
> set the mode with a mode SETATTR at any time, etc.
>
>> But let's pretend that all NFSv4 clients do support the ACL
>> attribute. Having the chmod command unable to set the mode was a
>> source of many customer complaints when that was the behavior in
>> Solaris (http://xrl.us/pd7c and http://xrl.us/pd7b are just two
>> examples of bugs). The Solaris chmod command was fixed to alter the
>> POSIX-draft ACL (in file systems that support POSIX-draft ACLs), so
>> that chmod was actually able to change the mode. Since making this
>> change to chmod, complaints have stopped.
>
> Maybe nobody explained to users how to properly use ACLs to prevent
> this from
> happening? The behavior of Solaris chmod(1) is a potential security
> hole,
> although a small one only.
I remind you that in NFSv4, ACL is not a required attribute.
>> So, if we were to do as your proposed design says, and have
>> MODE4_RGRP, etc., not reflect the mode, then once again, we would
>> have to modify the chmod command to do more than the chmod() system
>> call. This is madness.
>
> This is not what I am proposing at all.
>
>> Or, we could simply have MODE4_RGRP, etc., reflect the mode of the
>> file.
>
> This *is* what I am proposing. A mode SETATTR also affects which
> permissions
> are effective in the ACL and which must be disabled, though. Both
> proposals
> disable permissions, but they do so using different mechanisms:
> your proposal
> introduces DENY ACEs spread throughout the ACL. My proposal sets
> masks, which
> are only applied in the access check algorithm. I argue that simply
> updating
> the masks is a much nicer way of achieving the same effect, and
> that it
> avoids the problems inherent to those DENY ACEs.
>
>>> Algorithm 5.6.3. is at least problematic because it enforces
>>> implementing
>>> masking of permissions using DENY ACEs, while an alternative
>>> design exists
>>> that achieves the same effects without the disadvantages of those
>>> DENY ACEs.
>>
>> That alternative introduces a new file attribute, which causes
>> problems for NFSv4.0, and for Windows servers.
>
> That's not true. There are several ways how we can deal with clients
You just ignored my comment about Windows servers.
> that do
> not understand masks:
>
> (1) we can apply the masks before exposing the ACL to such
> clients, or
>
> (2) we can introduce DENY ACEs where necessary, as per your proposal.
>
> With (2), we are back to the problems with DENY ACEs: clients which
> reorder
> ACEs as (at least some versions of) Windows do will cause havoc.
> *But* we
> will never run into any such effects with clients that *do*
> understand masks,
> we don't have to bloat ACLs all the time,
>
> On the other hand, with (1), an ACL read-modify-write cycle will
> potentially
> lose some information, but the huge benefit is that the ACLs that
> clients
> will see will actually make some sense to them, instead of being
> littered
> with DENY ACEs that nobody will know how to deal with. Of course
> clients that
> understand masks will be fine as well.
>
> With both mechanisms, knocking the right mask bits in place in the
> ACL will
> cause these bits to become effective (provided that other ACEs
> don't deny
> them earlier in the ACL).
>
>>> The paragraphs below "3. To conform with POSIX" is lossy, even
>>> with the
>>> six-entry ACL that "2. If there are at least six ACEs" would
>>> create, which is a very unfavorable property.
>>
>> No, it is not lossy with the six-entry ACE in "2. ...". That's
>> because the six-entry ACE in "2." will be adjusted in the "3."
>> immediately following "2.".
>>
>> In general, the algorithm can be lossy, when modes such as 077 are
>> assigned to files having ACLs that grant read/write/execute to
>> supplemental groups.
>
> Exactly, the algorithm is lossy with supplemental groups. I misread
> that "3.
> To conform with POSIX" only applies to explicit groups. My point
> still stands
> though.
> Where does the algorithm deal with explicit users?
Section 5.6.3, step 1.5.2, if I understand your question correctly.
> Masks are not lossy per se, they will only become lossy when
> talking to
> clients that don't understand masks
In other words, they can be lossy.
> (and in those cases, the effects will
> never be worse than with DENY ACEs).
The effects can be worse than with DENY ACEs. I can think of an
improvement to the existing algorithm that would make it be POSIX
compliant and not be lossy, even in the face of setting mode 077.
With your design, you cannot avoid being lossy in the face of NFSv4.0
clients.
It is an issue that the masks can be lossy, but it is a greater issue
that they are lossy with certain classes of clients, and not lossy
with others.
>>> It also does not cover the case where the owner
>>> is granted permissions from EVERYONE@ ACEs, or where users or
>>> groups matching
>>> user@domain or group@domain are granted permissions from EVERYONE@
>>> ACEs.
>>
>> EVERYONE@ ACEs are covered. Re-read the algorithm.
>
> Ah, I see now, "3. To conform with POSIX" only refers to explicit
> groups.
>
>>> I can't see a compelling reason for requiring the exact six-entry
>>> ACL as specified in "2. If there are at least six ACEs".
>>
>> The goal of that step is to re-use the final six ACEs if possible, so
>> that successive changes to the mode don't cause a growing ACL.
>
> There is no reason for requiring this exact six-entry ACL other
> that that the
> algorithm you have chosen relies on this exact form. Other
> algorithms may be
> just fine with something completely different. I don't think that
> NFSv4.1
> should limit implementations in ways like this.
>
>>> Finally, I have argued why it is wrong to have a mode SETATTR write
>>> through to USER@, GROUP@, and EVERYONE@ ACEs.
>>
>> To not do so leaves you in the situation where a client that supports
>> the mode attribute and not the ACL attribute cannot set the mode.
>
> Not true. What makes you think so?
Again, substitute "set the mode" with "control read/write/execute for
owner/owner_group/other".
* * *
This thread has gone on long enough.
I will concede the following points: (1) Andreas' design will most
likely be POSIX compliant; (2) the algorithms in draft-ietf-nfsv4-
minorversion1-04.txt can produce ACLs that have ALLOW ACEs appearing
in front of DENY ACEs, potentially confusing the Windows ACL GUI,
even in cases where it's possible to have a semantically equivalent
ACL without the ALLOW/DENY ordering.
I will assert the following points: (1) The current algorithms are
POSIX compliant, and any attempts to show otherwise have failed; (2)
Andreas' design requires a new file attribute, thus causing problems
for Windows servers and inconsistent behavior between NFSv4.0 clients
and clients that support the new mode; (3) Andreas' design makes it
impossible to control read/write/execute permissions for owner/
owner_group/other without manipulating the ACL attribute.
I have proposed that the ACL text in the minorversion1 draft be
revised such that the current algorithms are not required, and that
the goals and requirements of the design are explicitly stated. Can
we end this thread until the revised ACL section has reached an
initial draft?
- Sam
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
On Tue, Jul 25, 2006 at 10:59:25PM -0600, Sam Falkner wrote:
> On Jul 25, 2006, at 2:15 PM, Andreas Gruenbacher wrote:
> >Maybe nobody explained to users how to properly use ACLs to prevent
> >this from happening? The behavior of Solaris chmod(1) is a potential
> >security hole, although a small one only.
>
> I remind you that in NFSv4, ACL is not a required attribute.
That's really a statement about servers, not clients, so I'm not
convinced it's relevant here.
It's true that servers are not required to support optional attributes.
But obviously clients may be required to do so if, for example, they
want full control over file permissions.
The chmod-modifies-group-bits scheme only removes one of the more
visible consequences of this fact.
--b.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Jul 21, 2006 at 11:10:04AM -0400, Noveck, Dave wrote:
> > Rethinking, it would be preferable to have the ACL specification
> > specify requirements, and have the algorithms serve as examples.
>
> I think the requirements that the algorithms are intended to address,
> would be helpful in understanding, whether the algorithms are
> examples or are mandatory.
Yes. My point wasn't necessarily that they should not be mandatory
(though I think they probably shouldn't be--I'm not yet convinced
they're actually correct), but that we need clarified whether they're
mandatory or not, and what requirements they're meant to meet, before we
can evaluate them properly.
> 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.
But I don't care whether they're incorporated by reference or copying.
--b.
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
On Jul 21, 2006, at 12:10 PM, J. Bruce Fields wrote:
> On Fri, Jul 21, 2006 at 11:10:04AM -0400, Noveck, Dave wrote:
>>> Rethinking, it would be preferable to have the ACL specification
>>> specify requirements, and have the algorithms serve as examples.
>>
>> I think the requirements that the algorithms are intended to address,
>> would be helpful in understanding, whether the algorithms are
>> examples or are mandatory.
>
> Yes. My point wasn't necessarily that they should not be mandatory
> (though I think they probably shouldn't be--I'm not yet convinced
> they're actually correct), but that we need clarified whether they're
> mandatory or not, and what requirements they're meant to meet,
> before we
> can evaluate them properly.
If you have any concerns about their correctness, please let me
know. As of now, there has not been a single example showing a flaw
in them. I realize this is difficult without having the requirements
listed explicitly -- this will be remedied very soon.
>> 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.
>
> But I don't care whether they're incorporated by reference or copying.
Issue 93 is tracking this. Anyone else having opinions should voice
them.
- Sam
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
On Sunday, 23. July 2006 17:47, Sam Falkner wrote:
> On Jul 21, 2006, at 12:10 PM, J. Bruce Fields wrote:
> > On Fri, Jul 21, 2006 at 11:10:04AM -0400, Noveck, Dave wrote:
> >>> Rethinking, it would be preferable to have the ACL specification
> >>> specify requirements, and have the algorithms serve as examples.
> >>
> >> I think the requirements that the algorithms are intended to address,
> >> would be helpful in understanding, whether the algorithms are
> >> examples or are mandatory.
> >
> > Yes. My point wasn't necessarily that they should not be mandatory
> > (though I think they probably shouldn't be--I'm not yet convinced
> > they're actually correct), but that we need clarified whether they're
> > mandatory or not, and what requirements they're meant to meet,
> > before we can evaluate them properly.
>
> If you have any concerns about their correctness, please let me
> know. As of now, there has not been a single example showing a flaw
> in them.
There are several flaws, but the lack of clarity on what the algorithms are
meant to achieve makes this somewhat difficult to see.
> I realize this is difficult without having the requirements listed
> explicitly -- this will be remedied very soon.
Looking at draft-ietf-nfsv4-minorversion1-04.txt, I disagree with secion
5.4.1. "Discussion of EVERYONE@". Section 5.5. "Mode Attribute" claims that
MODE4_RGRP, MODE4_WGRP, MODE4_XGRP apply to the principals identified in the
owner_group attribute, while it's really the File Group Class according to
POSIX. From that pretty much follows that the algorithm defined in Section
5.6.1. is not POSIX compliant: the File Group Class permissions must be a
superset of the permissions of the permissions granted to all ACEs for a who
other than OWNER@ and EVERYONE@, and the 5.6.1. algorithm does not guarantee
this.
Algorithm 5.6.3. is at least problematic because it enforces implementing
masking of permissions using DENY ACEs, while an alternative design exists
that achieves the same effects without the disadvantages of those DENY ACEs.
The paragraphs below "3. To conform with POSIX" is lossy, even with the
six-entry ACL that "2. If there are at least six ACEs" would create, which is
a very unfavorable property. It also does not cover the case where the owner
is granted permissions from EVERYONE@ ACEs, or where users or groups matching
user@domain or group@domain are granted permissions from EVERYONE@ ACEs.
I can't see a compelling reason for requiring the exact six-entry ACL as
specified in "2. If there are at least six ACEs".
Finally, I have argued why it is wrong to have a mode SETATTR write through to
USER@, GROUP@, and EVERYONE@ ACEs.
I have described a lot of aspects to the problem both here on this list and in
a design document, available at
http://www.suse.de/~agruen/nfs4acl/mapping-nfsv4-acls-to-posix-00.html, and I
would very much appreciate if you could comment on which parts you disagree
with and why, in order so that we can come to a conclusion on what we want to
achieve. I am convinced that once we agree on the basic framework we operate
within, how to do so will become a lot more obvious.
If you think that I should better provide input in another form then please
say so, and I will try my best.
Thanks,
Andreas
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Jul 21, 2006, at 9:10 AM, Noveck, Dave wrote:
>> The current ACL spec, in the minorversion1 draft and in the previous
>> ACL drafts, rigorously specifies mode/ACL interactions by specifying
>> algorithms. Bruce had the comment that the spec read as though the
>> algorithm was mandatory.
>
> That was my reading. Was that the intention or not?
It was, but note that there were many optional steps. The problem
we've since come to recognize is that there may be other algorithms
that do the job, and we don't want to disallow that.
>> Rethinking, it would be preferable to have the ACL specification
>> specify requirements, and have the algorithms serve as examples.
>
> I think the requirements that the algorithms are intended to address,
> would be helpful in understanding, whether the algorithms are
> examples or are mandatory.
Agreed.
>> Or,
>> rewrite the sections as requirements, and release algorithms outside
>> the minorversion1 draft, possibly through one or more informational
>> RFCs. This would shorten the minorversion1 draft, without
>> 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.
I agree. How about this: we move the algorithms into an appendix of
minorversion1. The appendix will expressly state that the algorithms
are illustrative. By having them in an appendix, they will be
available, as opposed to moving them toward a separate informational
RFC.
>> We'll try to have an initial draft of the ACL parts of the
>> minorversion1 document on August 7. I'll also add an issue to nfs4-
>> 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.
Done.
> I don't see the point of allowing multiple behaviors in the
> case in
> which both MODE and ACL are set. Rather than rell the client
> how to
>
> deal with all possible server behaviors, consider mandating the
> order
> in which a SETATTR/CREATE with both MODE and ACL will be processed
> by
> 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
> which order the changes will be done in.
Done. Yes, this is much simpler.
* * *
Okay, here's the revised text.
http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/file29/acls.txt
Please forgive the fact that the appendix appears as "Section 3"; it
will eventually land in a proper appendix.
Regarding Spencer's question from before, about "ACL compatibility
goals for NFSv4.1", this revised chapter qualifies as additional
explanatory text. Nothing is broken from RFC 3530, only clarified.
Nothing new is proposed. To my knowledge, the clients and servers
that have been tested at the various Connectathon and Bakeathon
events are fine with this spec.
- Sam
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wednesday, 26 July 2006 06:59, Sam Falkner wrote:
> On Jul 25, 2006, at 2:15 PM, Andreas Gruenbacher wrote:
> >> But let's pretend that all NFSv4 clients do support the ACL
> >> attribute. Having the chmod command unable to set the mode was a
> >> source of many customer complaints when that was the behavior in
> >> Solaris (http://xrl.us/pd7c and http://xrl.us/pd7b are just two
> >> examples of bugs). The Solaris chmod command was fixed to alter the
> >> POSIX-draft ACL (in file systems that support POSIX-draft ACLs), so
> >> that chmod was actually able to change the mode. Since making this
> >> change to chmod, complaints have stopped.
> >
> > Maybe nobody explained to users how to properly use ACLs to prevent
> > this from happening? The behavior of Solaris chmod(1) is a potential
> > security hole, although a small one only.
>
> I remind you that in NFSv4, ACL is not a required attribute.
I think this point has already become clear, but just so that it doesn't
appear as if I'm selectively ignoring your arguments, let me reiterate:
I did not miss the fact that NFSv4 implementations may choose not to implement
the ACL attribute. In the mapping I am proposing, the mode attribute always
reflects the file mode permission bits. On a POSIX server that doesn't
support the ACL attribute, the mode attribute represents the file mode
permission bits which determine access.
On the other hand, a server which does support the ACL attribute, the ACL may
induce further restrictions on the permissions granted by the mode attribute.
In case any alternate ACE mode bits are set which are not disabled, the ACL
may also grant permissions that go beyond the file mode permission bits.
[For servers that don't support the ACL attribute, it obviously also makes no
sense to support file masks.]
> >> So, if we were to do as your proposed design says, and have
> >> MODE4_RGRP, etc., not reflect the mode, then once again, we would
> >> have to modify the chmod command to do more than the chmod() system
> >> call. This is madness.
> >
> > This is not what I am proposing at all.
> >
> >> Or, we could simply have MODE4_RGRP, etc., reflect the mode of the
> >> file.
> >
> > This *is* what I am proposing. A mode SETATTR also affects which
> > permissions are effective in the ACL and which must be disabled, though.
> > Both proposals disable permissions, but they do so using different
> > mechanisms: your proposal introduces DENY ACEs spread throughout the
> > ACL. My proposal sets masks, which are only applied in the access check
> > algorithm. I argue that simply updating the masks is a much nicer way of
> > achieving the same effect, and that it avoids the problems inherent to
> > those DENY ACEs.
> >
> >>> Algorithm 5.6.3. is at least problematic because it enforces
> >>> implementing masking of permissions using DENY ACEs, while an
> >>> alternative design exists that achieves the same effects without the
> >>> disadvantages of those DENY ACEs.
> >>
> >> That alternative introduces a new file attribute, which causes
> >> problems for NFSv4.0, and for Windows servers.
> >
> > That's not true. There are several ways how we can deal with clients
> > that do not understand masks:
>
> You just ignored my comment about Windows servers.
Not on purpose. I'll assume that your comment is that Windows servers do not
(and probably will not) support the proposed file_masks attribute, which is
pretty much the same situation as with NFSv4 (RFC3530) servers that also
don't support this attribute.
On such a server, nothing prevents users from setting arbitrary ACLs. POSIX
applications running on the client may chmod files, which maps to mode
SETATTR calls. Because RFC3530 does not define the interaction between a mode
SETATTR and the ACL attribute, those servers obviously are not guaranteed to
implement strict POSIX semantics.
We could map a chmod to an ACL GETATTR, inject DENY ACEs on the client side as
required, and then set both the new mode and the modified ACL. This would
give us pretty good POSIX semantics, but implementing this hack on the client
side sounds pretty ugly to me.
Is this what you were envisioning?
I believe that a more sane approach would be to accept that non-POSIX NFSv4
servers will not have strict POSIX semantics, and live with the fact.
Andreas
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Sorry this reply took a while; I was away for a couple of days.
On Tuesday, 25 July 2006 06:26, Sam Falkner wrote:
> A more detailed analysis is forthcoming; for now, here's an early
> summary of objections.
>
> Your design tries very hard to preserve information in ACLs while
> retaining POSIX compliance at chmod() and create-with-mode time. It
> does this by introducing a new file attribute. The file attribute
> will not be understood by an NFSv4.0 client or server. Thus, when an
> NFSv4.0 client manipulates the ACL via read/modify/write, it has just
> destroyed the information you tried to preserve within the ACL.
This depends on how backwards compatibility is implemented. I could imagine
two options: (1) present NFSv4.0 clients/servers with ACLs that have all
disabled mask bits removed, or (2) inject DENY ACEs in that case, similiar to
draft-ietf-nfsv4-acls-00.
Let's look at NFSv4.0 clients first. With option (1), the client will see an
ACL which is relatively simple to understand compared to option (2). After an
ACL read/modify/write cycle, mask bits that were temporarily disabled before
will be permanently disabled. In other words, the file will at most have the
permissions defined in the ACL until the ACL is modified again, and future
mode SETATTRs may further restrict those permissions, but will not elevate
them relative to the ACL.
I argue that in an ACL read/modify/write cycle, users will set exactly the
mask bits they intend the file to have, and so mask bits that were
temporarily disabled before the ACL read/modify/write cycle and which the
user did not explicitly set are not needed.
Masking is still important when POSIX applications manipulate file
permissions: for example, a linker may create an object file with create mode
0600 in a directory that has file inheritable ACEs, produce the whole file,
and finally change the file mode to 0755. Masking causes sequences of POSIX
operations like this to have the intended effect.
With option (2), the unsuspecting client will see a more complicated ACL that
it may or may not be able to edit properly. It is unlikely that the ACL
editor on the client will understand the masking mechanism, and it is equally
unlikely that users will edit the ACL correctly so that none of the masked
information will be lost, even if the ACL editor supports it. In Windows, the
ACL editor will probably reorder ACL entries and move all DENY ACEs to the
front, and so masking will break, for example. So I'm not convinced that the
more complicated approach will actually gain us anything.
Let's look at NFSv4.0 servers now. The interesting operation in this case is a
chmod on the client. The client could either (a) do a mode SETATTR, or (b)
retrieve the ACL via GETATTR, modify it according to the new mode, and set
the new ACL and mode via SETATTR. In option (b), we can again either (1)
remove disabled permissions permanently, or (2) introduce DENY ACEs to do the
masking.
I believe that we should implement option (a), and rely on the server to do
the right thing: trying to implement POSIX behavior on the client side may
interact badly with the ACLs support the NFSv4.0 server implements. (Servers
may map NFSv4 ACLs onto a different kind of ACLs that support different
semantics, for example.)
Implementing option (b) (2) could give us better POSIX semantics on non-POSIX
servers like Windows. I am not convinced that the drawbacks of setting ACLs
on Windows files that users will have a very hard time to understand and that
Windows probably cannot edit are outweighed by the benefit of pretending that
a Windows server is POSIX compliant. UNIX servers will probably benefit more
from having their NFSv4 server updated so that a mode SETATTR does the right
thing than from such hacks.
> Nor will the new file mask attribute be implemented natively on a
> Windows file system. Thus, Windows servers will have significantly
> different access semantics for NFS clients than for users accessing
> the file system locally.
The same mask bits will be effective in both cases, so the access semantics
are the same. A client that understands masks will additionally see which
mask bits are currently disabled, but this does not change access decisions.
> An NFS server giving different answers for "what is the ACL",
> depending on who's asking or how are they asking, will lead to
> confusion and frustration for end users.
I don't see why this should be the case. Clients that understand masks can ask
a more intelligent question and will get more information. Of course those
clients must also present the masks to the user together with the ACL, and
preferably indicate somehow which mask bits are temporarily disabled.
I claim that the mask DENY ACEs that draft-ietf-nfsv4-acls-00 uses are harder
to understand than the mask attributes. Both approaches implement the same
mechanism via different means. The masks implement masking explicitly; the
DENY ACEs implement masking implicitly and it is harder to see which
permissions are effective: The mask attributes define the maximum permissions
that the ACL may grant; with DENY ACEs, the entire ACL needs to be carefully
checked. Also, it is not guaranteed that the DENY ACEs are in fact consistent
after a user has modified the ACL.
> One thing I'm very curious about is what you would expect an NFS
> client that supports the new access-mask-file-attribute to do with a
> server that does not support this attribute. I cannot see a
> satisfactory outcome, but I won't call this a flaw yet, since your
> design is still being worked on.
I tried to answer this above. draft-ietf-nfsv4-acls-00 does not discuss this
aspect, by the way: how did you intend to implement chmod on such a client?
> Finally, your design also specifies that the mode attribute not
> reflect the file mode. It makes it impossible for a non-ACL-aware
> client to reliably get or set the owner/group/other permissions on a
> file. Even on an ACL-aware client, it demands that end user
> utilities understand and support NFSv4 ACLs in order to set the mode
> of a file.
This is incorrect, and I believe we have clarified this already. The mode
attribute does reflect the POSIX file mode in my proposal.
> It also advocates umask behavior that is not legal within POSIX, but
> that is outside the scope of NFS.
It advocates umask behavior that is not legal within POSIX for good reasons.
The proposed behavior is specified in 1003.1e draft 17 (withdrawn). It has
been implemented on several UNIX-like OSes for POSIX ACLs, and has been in
production use on many installations for years.
Please argue against the reasons I have given if you disagree with the
proposed behavior instead of hitting at me with the "illegal by POSIX" stick.
Thanks,
Andreas
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Aug 3, 2006, at 6:30 PM, Andreas Gruenbacher wrote:
> Sorry this reply took a while; I was away for a couple of days.
I could write an extremely lengthy rebuttal to your extremely lengthy
reply :-), but please, let's wait until the meeting next week. I
will try to have a draft of the revised ACL chapter before then...
hopefully tomorrow.
Thanks!
- Sam
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday 04 August 2006 03:37, Sam Falkner wrote:
> On Aug 3, 2006, at 6:30 PM, Andreas Gruenbacher wrote:
> > Sorry this reply took a while; I was away for a couple of days.
>
> I could write an extremely lengthy rebuttal to your extremely lengthy
> reply :-), but please, let's wait until the meeting next week.
Please do, so that I'll know what you disagree with, and why. The more issues
of dispute we can clearly identify before the meeting, the better.
> I will try to have a draft of the revised ACL chapter before then...
> hopefully tomorrow.
That would be really helpful.
Thanks,
Andreas
--
Andreas Gruenbacher <[email protected]>
Novell / SUSE Labs
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday 04 August 2006 03:37, Sam Falkner wrote:
> On Aug 3, 2006, at 6:30 PM, Andreas Gruenbacher wrote:
> > Sorry this reply took a while; I was away for a couple of days.
>
> I could write an extremely lengthy rebuttal to your extremely lengthy
> reply :-), but please, let's wait until the meeting next week.
Please do, so that I'll know what you disagree with, and why. The more issues
of dispute we can clearly identify before the meeting, the better.
> I will try to have a draft of the revised ACL chapter before then...
> hopefully tomorrow.
That would be really helpful.
Thanks,
Andreas
--
Andreas Gruenbacher <[email protected]>
Novell / SUSE Labs
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs