It seems like this is what most users would want. It doesn't seem to=20
match what is specified in section 3.16.6.3 of draft-03. That says
the acl is modified when you change the mode.
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
-----Original Message-----
From: Sam Falkner [mailto:[email protected]]=20
Sent: Tuesday, July 18, 2006 6:09 PM
To: Noveck, Dave
Cc: J. Bruce Fields; Lisa Week; [email protected];
[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 16, 2006, at 7:10 AM, Noveck, Dave wrote:
> What does Solaris do about chmod +s? Does it modify the ACL?
No -- chmod +s leaves the ACL (if any) alone, and only affects the
setuid bit.
- Sam
> -----Original Message-----
> From: Sam Falkner [mailto:[email protected]]
> Sent: Saturday, July 15, 2006 9:56 AM
> To: J. Bruce Fields
> Cc: Lisa Week; [email protected]; [email protected]; Spencer=20
> Shepler; Pawlowski, Brian; Andreas Gruenbacher
> Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /=20
> 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=20
>>> the group permissions and the mask, simultaneously. I now=20
>>> understand
>
>>> why you were hesitant to have chmod affect the group permissions,=20
>>> 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=20
>> "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=20
>> chmod's that leaves the mode bits the same also leaves the ACL the=20
>> same. I agree that that's a nice property.
>
> Perhaps, but I think having chmod unable to set the mode to be a much=20
> more undesirable property, to put it mildly.
>
>> What I'm not convinced of yet is that this is really worth caring=20
>> about much. Is this common application behavior? Have there been=20
>> complaints about this from people using Solaris's ACLs?
>
> I did some more research, and found that the Solaris chmod() system=20
> call does pretty much what Linux does -- the group permissions of
> chmod() affect the mask, not the group permission bits. =20
> 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=20
> presence of an ACL, fix the permission bits. In other words, the bug=20
> was fixed.
>
> I have found no complaints about the current Solaris behavior, where=20
> chmod affects group permissions.
>
> - Sam
>
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nfsv4
>
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
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
POSIX-draft ACLs, and not NFSv4 ACLs. In the case of NFSv4 ACLs (on
ZFS), it does change the ACL, whether you use "+s" or "4xxx". In my
test, it added a mask ACE for the supplemental user I had added
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
to set the setuid bit in the mode, unless the mode requires changes
to the ACL for POSIX conformance. The mode might require changing
the ACL more times than is obvious, but the ACL specification
shouldn't require unnecessary changes to the ACL...
Here's an idea. It's not an original idea, it's one that Bruce
proposed last April, and unfortunately his comments went unanswered
(mea culpa).
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.
Rethinking, it would be preferable to have the ACL specification
specify requirements, and have the algorithms serve as examples. 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.
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.
- Sam
(Read on if you're interested in implications.)
This would make it possible to craft different algorithms that can
still meet the ACL spec in minorversion1. Take this example single-
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
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/
write_owner::ALLOW
GROUP@:write_data/append_data::DENY
GROUP@:read_data/execute::ALLOW
EVERYONE@:write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner::DENY
EVERYONE@:read_data/read_xattr/execute/read_attributes/read_acl/
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
was necessary)
EVERYONE@:read_data/execute::ALLOW
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4