What does Solaris do about chmod +s? Does it modify the ACL?
-----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
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
[email protected]
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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
> 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nfsv4
>
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nfsv4
-------------------------------------------------------------------------
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