ZFS introduces a new and incompatible ACL interface into
Solaris and this seems to be not yet fully completed in addition
to the fact that is causes a lot of problems for software that
needs to be compatible with Solaris-2.5 like star.
Proof for incompatibility:
create a file on UFS and set an ACL for this file.
Use Sun tar cpf out file to archive this file.
Unpack this archive file on ZFS ---> works.
mv file file2
Use Sun tar cpf out2 file2 to archive this file also.
Upack the second archive file on UFS ---> does not work.
This is not acceptable behavior.....
Some additional notes:
CPIO is outdated, so I don''t check or talk about cpio at all.
Sun''s tar is not portable and does not create portable archives,
so it may look to Sun employees that there is no need to create
a compatible interface.
Sun''s tar is not even able to backup/restore UFS ACLs correctly on
the same file server in case that there is no YP on the server
because of bugs in acltext.c that I did report long ago but Sun
refuses to fix. Sun states that there are no bugs :-(
Star on the other side supports to archive and extract ACLs on
Solaris, SGI-IRIX, FreeBSD & Linux and defines an archive format that
allows to have full ACL compatibility between all these platforms.
As Cygwin did copy Sun''s ACL interface on Win32, star should even
be compatible with Cygwin (not yet tested).
In order to allow this to happen, star uses acl_get_file(name, type)
and acl_to_text() on fully POSIX systems and acl() / acltotext(aclp, aclcount)
on Solaris like systems. Then star does text processing on the resultant
string to allow portable archives. To do this, star uses an abstract
format that basically adds another (numerical) ID field to the POSIX
ACL string.
Adding a new incompatible ACL interface (as Sun did) that cannot be
easily used to create portable archives is a bad thing and could have been
avoided if Sun did ask me before....
How do we proceed?
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Wed, 2005-11-23 at 22:43, Joerg Schilling wrote:> ZFS introduces a new and incompatible ACL interface into > Solaris and this seems to be not yet fully completed in addition > to the fact that is causes a lot of problems for software that > needs to be compatible with Solaris-2.5 like star.Thats because the old ACL interface was confusing to users, and didn''t actually do what customers wanted from ACLs (due to the really messy interaction with the UMASK and several other missing features). Or in a single word "RUBBISH" [ or GARBAGE or TRASH in American - see I did learn something from my 5 years in California :-) ]. The new ZFS ACL are compatible with NFSv4 ACL which are derived from Windows NT ACL. If you look at the acl(2) man page you will see that the API as been extended in a compatible way and that ZFS and NFSv4 used ace_t and UFS uses the old aclent_t. The chmod(1) man page show how different these ACL systems really are the NFSv4 style ACL are what customers want and need. You will also see in the ATTRIBUTES section that we claim this interface is Evolving and this was an upwards compatible change. We do NOT claim this is an interface that implements a Standard.> Sun''s tar is not even able to backup/restore UFS ACLs correctly on > the same file server in case that there is no YP on the server > because of bugs in acltext.c that I did report long ago but Sun > refuses to fix. Sun states that there are no bugs :-(Bug numbers please, I could not find any bugs that could be the one you mentioned. We don''t fix every single bug, every bug fix takes time and resources to fix. If you are certain there is a bug and you believe it is important enough you could now fix it yourself, if you can convince me I''ll even sponsor the fix putback for you.> In order to allow this to happen, star uses acl_get_file(name, type) > and acl_to_text() on fully POSIX systems and acl() / acltotext(aclp, aclcount)Exactly which non defunct POSIX standard includes ACL (not an abandoned draft)? As far as I know there isn''t one, there is a defunct POSIX draft on ACLs that that is what the UFS ACLs are modelled on. If there is a ratified POSIX standard that includes ACLs I''d love to read it so please send a pointer. On the other hand there is an IETF Standard for the ACLs used in ZFS - its part of the NFSv4 specification. So what does star do with ACL on Windows or on NFSv4 ? -- Darren J Moffat
>On Wed, 2005-11-23 at 22:43, Joerg Schilling wrote: >> ZFS introduces a new and incompatible ACL interface into >> Solaris and this seems to be not yet fully completed in addition >> to the fact that is causes a lot of problems for software that >> needs to be compatible with Solaris-2.5 like star. > >Thats because the old ACL interface was confusing to users, and didn''t >actually do what customers wanted from ACLs (due to the really messy >interaction with the UMASK and several other missing features). Or in a >single word "RUBBISH" [ or GARBAGE or TRASH in American - see I >did learn something from my 5 years in California :-) ].You know that that the "umask" interaction is up to debate; the fact that ZFS default ACLs now again requires UMASK to be set to 0 is a bug, not a feature. A bug we fixed in UFS because everybody concerned said that the default ACLs were useless if they were also interesected by the umask. Casper
On Thu, 2005-11-24 at 14:43, Casper.Dik at Sun.COM wrote:> >On Wed, 2005-11-23 at 22:43, Joerg Schilling wrote: > >> ZFS introduces a new and incompatible ACL interface into > >> Solaris and this seems to be not yet fully completed in addition > >> to the fact that is causes a lot of problems for software that > >> needs to be compatible with Solaris-2.5 like star. > > > >Thats because the old ACL interface was confusing to users, and didn''t > >actually do what customers wanted from ACLs (due to the really messy > >interaction with the UMASK and several other missing features). Or in a > >single word "RUBBISH" [ or GARBAGE or TRASH in American - see I > >did learn something from my 5 years in California :-) ]. > > You know that that the "umask" interaction is up to debate; > the fact that ZFS default ACLs now again requires UMASK to be > set to 0 is a bug, not a feature.Isn''t this what the aclmode= setting is designed to help with ? -- Darren J Moffat
On Thu, 2005-11-24 at 14:21, Darren J Moffat wrote:> Thats because the old ACL interface was confusing to users, and didn''t > actually do what customers wanted from ACLs (due to the really messy > interaction with the UMASK and several other missing features). Or in a > single word "RUBBISH" [ or GARBAGE or TRASH in American - see I > did learn something from my 5 years in California :-) ].I beg to differ. The (now) traditional acl interface was simple, straightforward, and did its job very well. The original implementation suffered from having a wierd and unwanted interaction with the user''s umask, but that was fixed a long time ago. Yes, the setfacl command was imperfect, and the permissions set not as rich as one might have wished for, but it had the fundamental property of working as desired. Basically, the old acl interface did exactly what a lot of us wanted.> The chmod(1) man page show how different these ACL systems > really are the NFSv4 style ACL are what customers want and need.OK, what I need is something that forces all newly created files in a directory to be mode 660 (or 770 for executables) no matter what. Traditionally, I would use d:u::rwx,d:g::rwx,d:m:rwx,d:o:--- on the directory and it works exactly as desired. What''s the new chmod syntax to do this on zfs? -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Peter Tribble <P.Tribble at herts.ac.uk> wrote:> On Thu, 2005-11-24 at 14:21, Darren J Moffat wrote: > > > Thats because the old ACL interface was confusing to users, and didn''t > > actually do what customers wanted from ACLs (due to the really messy > > interaction with the UMASK and several other missing features). Or in a > > single word "RUBBISH" [ or GARBAGE or TRASH in American - see I > > did learn something from my 5 years in California :-) ]. > > I beg to differ. > > The (now) traditional acl interface was simple, straightforward, and > did its job very well. The original implementation suffered from having > a wierd and unwanted interaction with the user''s umask, but that was > fixedI need to concur.... The POSIX interface is not as easy to understand but after some time you understand it and really grok it so you may use it without thinking. The current NFSv4 interface in Solaris has some advantages: - It supports something that I am missing sine 21 years when I added this feature to a UNIX clone in 1984: The delete flag. - It supports something that FreeBSD implements for UFS: Append only. The problem with this interface is that: - It is much more complex than the POSIX interface - It uses a hard to visualize method to print. Text is much harder to apprehend than a list of single characters.... - The deny entries make it even harder to understand then allow entries - Sun managed it to create an unusable TAR ACL interface for a second time. This is caused by the fact that the interface used by Sun tar does not include the numerical uid/gid. I would call the current state of the implementation "alpha" because there is at least the need to introduce an incompatible interface change to the TAR ACL method. This file uses a real simple ACL: -rw-r--r-- 1 joerg 300 0 Nov 24 21:45 file 0:user::rw- 1:group::r-- #effective:r-- 2:mask:r-- 3:other:r-- Converted to NFSv4 it is unreadable :-( -rw-r--r--+ 1 joerg 300 0 Nov 24 21:45 file 0:owner@:read_data/write_data/append_data/read_attributes /write_attributes/read_acl/write_acl/synchronize:allow 1:owner@:execute:deny 2:user:root:write_data/append_data/execute/write_attributes/write_acl :deny 3:user:root:read_data/write_data/append_data/execute/read_attributes /read_acl/synchronize:allow 4:user:root:write_attributes/write_acl:deny 5:group@:write_data/append_data/execute/write_attributes/write_acl:deny 6:group@:read_data/read_attributes/read_acl/synchronize:allow 7:group@:write_data/append_data/execute/write_attributes/write_acl:deny 8:everyone@:read_data/read_attributes/read_acl/synchronize:allow 9:everyone@:write_data/append_data/execute/write_attributes/write_acl :deny I would really like to see an explanation why the entry #4 exists at all.... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Sun, Nov 27, 2005 at 01:06:19AM +0100, Joerg Schilling wrote:> > The problem with this interface is that: > > - It is much more complex than the POSIX interfaceYes, but as mentioned by Darren, it is a standard (unlike the withdrawn POSIX interpretation) that actually stands a chance of being used on more than one platform.> - It uses a hard to visualize method to print. > Text is much harder to apprehend than a list > of single characters....If you can come up with a way of visualizing all possibilities, please let us know. We have a few months while this sits in Nevada to play with the interfaces. The current interfaces (particularly chmod) were modeled largely after Apple''s implementation.> - The deny entries make it even harder to understand then > allow entriesYes, but this is an explicit requirement from our customers and the community at large (including the original NT ACLs and the NFSv4 derived spec). Not having this functionality is not an option.> - Sun managed it to create an unusable TAR ACL interface for a second > time. This is caused by the fact that the interface used by > Sun tar does not include the numerical uid/gid.File a bug. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Sun, 2005-11-27 at 01:24, Eric Schrock wrote:> We have a few months while this sits in Nevada to play > with the interfaces. The current interfaces (particularly chmod) were > modeled largely after Apple''s implementation.Well, one possibility is to simplify chmod. I''m assuming that the permission bits r, w, and x each map onto a group of ACL permissions. In that case, why not allow the use of rwx as a shorthand which expands to the appropriate set of permissions? -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Joerg Schilling wrote:> Peter Tribble <P.Tribble at herts.ac.uk> wrote: > > >>On Thu, 2005-11-24 at 14:21, Darren J Moffat wrote: >> >> >>>Thats because the old ACL interface was confusing to users, and didn''t >>>actually do what customers wanted from ACLs (due to the really messy >>>interaction with the UMASK and several other missing features). Or in a >>>single word "RUBBISH" [ or GARBAGE or TRASH in American - see I >>>did learn something from my 5 years in California :-) ]. >> >>I beg to differ. >> >>The (now) traditional acl interface was simple, straightforward, and >>did its job very well. The original implementation suffered from having >>a wierd and unwanted interaction with the user''s umask, but that was >>fixed > > > I need to concur.... > > The POSIX interface is not as easy to understand but after some time you > understand it and really grok it so you may use it without thinking. > > The current NFSv4 interface in Solaris has some advantages: > > - It supports something that I am missing sine 21 years when I added > this feature to a UNIX clone in 1984: The delete flag. > > - It supports something that FreeBSD implements for UFS: Append only. > > > The problem with this interface is that: > > - It is much more complex than the POSIX interface > > - It uses a hard to visualize method to print. > Text is much harder to apprehend than a list > of single characters.... > > - The deny entries make it even harder to understand then > allow entries >The "deny" entries give you a tremendous amount of flexibility. They allow you to exclude a single user while granting greater permissions to a large group for example: user:fred:read_data/write_data:deny group:staff:read_data/write_data/execute:allow <rest of ACL continues> Now assuming fred is a member of the group staff then you have just singled out "fred" from being allowed to read/write or execute the file.> - Sun managed it to create an unusable TAR ACL interface for a second > time. This is caused by the fact that the interface used by > Sun tar does not include the numerical uid/gid. > > I would call the current state of the implementation "alpha" because there > is at least the need to introduce an incompatible interface change to the > TAR ACL method. > > > This file uses a real simple ACL: > -rw-r--r-- 1 joerg 300 0 Nov 24 21:45 file > 0:user::rw- > 1:group::r-- #effective:r-- > 2:mask:r-- > 3:other:r-- > > Converted to NFSv4 it is unreadable :-( > > -rw-r--r--+ 1 joerg 300 0 Nov 24 21:45 file > 0:owner@:read_data/write_data/append_data/read_attributes > /write_attributes/read_acl/write_acl/synchronize:allow > 1:owner@:execute:deny > 2:user:root:write_data/append_data/execute/write_attributes/write_acl > :deny > 3:user:root:read_data/write_data/append_data/execute/read_attributes > /read_acl/synchronize:allow > 4:user:root:write_attributes/write_acl:deny > 5:group@:write_data/append_data/execute/write_attributes/write_acl:deny > 6:group@:read_data/read_attributes/read_acl/synchronize:allow > 7:group@:write_data/append_data/execute/write_attributes/write_acl:deny > 8:everyone@:read_data/read_attributes/read_acl/synchronize:allow > 9:everyone@:write_data/append_data/execute/write_attributes/write_acl > :deny > > I would really like to see an explanation why the entry #4 exists at all.... >Just how did you create this ACL? It looks like it is an ACL translated from UFS to ZFS? Is this file actually on UFS? Entry 4 above is not needed, but it doesn''t hurt anything either. Without knowing how the file was created I can''t determine if its correct behavior or if its a bug. A native ZFS ACL would look something like this, with one user ACL entry prepended to it. -rw-r--r--+ 1 marks staff 0 Nov 27 13:44 file.1 0:user:maybee:read_data/write_data:allow 1:owner@:execute:deny 2:owner@:read_data/write_data/append_data/ write_xattr/write_attributes /write_acl/write_owner:allow 3:group@:write_data/append_data/execute:deny 4:group@:read_data:allow 5:everyone@:write_data/append_data/ write_xattr/execute/write_attributes /write_acl/write_owner:deny 6:everyone@:read_data/read_xattr/ read_attributes/read_acl/synchronize :allow
Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:> > I would call the current state of the implementation "alpha" because there > > is at least the need to introduce an incompatible interface change to the > > TAR ACL method. > > > > > > This file uses a real simple ACL: > > -rw-r--r-- 1 joerg 300 0 Nov 24 21:45 file > > 0:user::rw- > > 1:group::r-- #effective:r-- > > 2:mask:r-- > > 3:other:r--Sorry for this wrong ACL data, it is a result of the tar ACL extract bug... Here is the correct UFS ACL: ls -v file -rw-r--r--+ 1 joerg 300 0 Nov 24 21:45 file 0:user::rw- 1:user:root:rwx #effective:r-- 2:group::r-- #effective:r-- 3:mask:r-- 4:other:r--> > Converted to NFSv4 it is unreadable :-( > > > > -rw-r--r--+ 1 joerg 300 0 Nov 24 21:45 file > > 0:owner@:read_data/write_data/append_data/read_attributes > > /write_attributes/read_acl/write_acl/synchronize:allow > > 1:owner@:execute:deny > > 2:user:root:write_data/append_data/execute/write_attributes/write_acl > > :deny > > 3:user:root:read_data/write_data/append_data/execute/read_attributes > > /read_acl/synchronize:allow > > 4:user:root:write_attributes/write_acl:deny > > 5:group@:write_data/append_data/execute/write_attributes/write_acl:deny > > 6:group@:read_data/read_attributes/read_acl/synchronize:allow > > 7:group@:write_data/append_data/execute/write_attributes/write_acl:deny > > 8:everyone@:read_data/read_attributes/read_acl/synchronize:allow > > 9:everyone@:write_data/append_data/execute/write_attributes/write_acl > > :deny > > > > I would really like to see an explanation why the entry #4 exists at all.... > > > > Just how did you create this ACL? It looks like it is an ACL translated > from UFS to ZFS? Is this file actually on UFS? > Entry 4 above is not needed, but it doesn''t hurt anything either. > Without knowing how the file was created I can''t determine if its > correct behavior or if its a bug.It was created with the set of commands I recently send out when I filed a bugreport against Sun tar. Thr problem with autoconverted ACLs is that you cannot convert them back properly unless you apply a cleanly defines conversion.> A native ZFS ACL would look something like this, with one user ACL entry > prepended to it. > > -rw-r--r--+ 1 marks staff 0 Nov 27 13:44 file.1 > 0:user:maybee:read_data/write_data:allow > 1:owner@:execute:deny > 2:owner@:read_data/write_data/append_data/ > write_xattr/write_attributes > /write_acl/write_owner:allow > 3:group@:write_data/append_data/execute:deny > 4:group@:read_data:allow > 5:everyone@:write_data/append_data/ > write_xattr/execute/write_attributes > /write_acl/write_owner:deny > 6:everyone@:read_data/read_xattr/ > read_attributes/read_acl/synchronize > :allowOK: then please explain me why there are deny entries in above ACL data. Why should #1 be needed at all? Why should #3 be needed at all? Why should #5 be needed at all? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:> Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote: > > >>>I would call the current state of the implementation "alpha" because there >>>is at least the need to introduce an incompatible interface change to the >>>TAR ACL method. >>> >>> >>>This file uses a real simple ACL: >>>-rw-r--r-- 1 joerg 300 0 Nov 24 21:45 file >>> 0:user::rw- >>> 1:group::r-- #effective:r-- >>> 2:mask:r-- >>> 3:other:r-- > > > Sorry for this wrong ACL data, it is a result of the tar ACL extract bug... > > Here is the correct UFS ACL: > > ls -v file > -rw-r--r--+ 1 joerg 300 0 Nov 24 21:45 file > 0:user::rw- > 1:user:root:rwx #effective:r-- > 2:group::r-- #effective:r-- > 3:mask:r-- > 4:other:r-- > > > >>>Converted to NFSv4 it is unreadable :-( >>> >>>-rw-r--r--+ 1 joerg 300 0 Nov 24 21:45 file >>> 0:owner@:read_data/write_data/append_data/read_attributes >>> /write_attributes/read_acl/write_acl/synchronize:allow >>> 1:owner@:execute:deny >>> 2:user:root:write_data/append_data/execute/write_attributes/write_acl >>> :deny >>> 3:user:root:read_data/write_data/append_data/execute/read_attributes >>> /read_acl/synchronize:allow >>> 4:user:root:write_attributes/write_acl:deny >>> 5:group@:write_data/append_data/execute/write_attributes/write_acl:deny >>> 6:group@:read_data/read_attributes/read_acl/synchronize:allow >>> 7:group@:write_data/append_data/execute/write_attributes/write_acl:deny >>> 8:everyone@:read_data/read_attributes/read_acl/synchronize:allow >>> 9:everyone@:write_data/append_data/execute/write_attributes/write_acl >>> :deny >>> >>>I would really like to see an explanation why the entry #4 exists at all.... >>> >> >>Just how did you create this ACL? It looks like it is an ACL translated >>from UFS to ZFS? Is this file actually on UFS? >>Entry 4 above is not needed, but it doesn''t hurt anything either. >>Without knowing how the file was created I can''t determine if its >>correct behavior or if its a bug. > > > It was created with the set of commands I recently send out when I filed > a bugreport against Sun tar. > > Thr problem with autoconverted ACLs is that you cannot convert them back > properly unless you apply a cleanly defines conversion. >All POSIX draft ACLs can be translated to NFSv4 ACLs, but only a small subset of NFSv4 ACLs can be translated to POSIX draft ACLs without loosing information in the process.> >>A native ZFS ACL would look something like this, with one user ACL entry >>prepended to it. >> >>-rw-r--r--+ 1 marks staff 0 Nov 27 13:44 file.1 >> 0:user:maybee:read_data/write_data:allow >> 1:owner@:execute:deny >> 2:owner@:read_data/write_data/append_data/ >> write_xattr/write_attributes >> /write_acl/write_owner:allow >> 3:group@:write_data/append_data/execute:deny >> 4:group@:read_data:allow >> 5:everyone@:write_data/append_data/ >> write_xattr/execute/write_attributes >> /write_acl/write_owner:deny >> 6:everyone@:read_data/read_xattr/ >> read_attributes/read_acl/synchronize >> :allow > > > OK: then please explain me why there are deny entries in above > ACL data. > > Why should #1 be needed at all?That is needed because the mode doesn''t grant execute> > Why should #3 be needed at all?Mode doesn''t grant write or execute> > Why should #5 be needed at all?Mode doesn''t grant write or execute, plus we want to take away a bunch of permissions that aren''t reflected in the mode.> > J?rg >
Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:> > It was created with the set of commands I recently send out when I filed > > a bugreport against Sun tar. > > > > Thr problem with autoconverted ACLs is that you cannot convert them back > > properly unless you apply a cleanly defines conversion. > > > > All POSIX draft ACLs can be translated to NFSv4 ACLs, but only a small > subset of NFSv4 ACLs can be translated to POSIX draft ACLs without > loosing information in the process.... and all NFSv4 ACLs that have been translated from UFS should allow to be translated back to UFS correctly. The fact that this doesn''t work today is why I did file a bug report.....> >>A native ZFS ACL would look something like this, with one user ACL entry > >>prepended to it. > >> > >>-rw-r--r--+ 1 marks staff 0 Nov 27 13:44 file.1 > >> 0:user:maybee:read_data/write_data:allow > >> 1:owner@:execute:deny > >> 2:owner@:read_data/write_data/append_data/ > >> write_xattr/write_attributes > >> /write_acl/write_owner:allow > >> 3:group@:write_data/append_data/execute:deny > >> 4:group@:read_data:allow > >> 5:everyone@:write_data/append_data/ > >> write_xattr/execute/write_attributes > >> /write_acl/write_owner:deny > >> 6:everyone@:read_data/read_xattr/ > >> read_attributes/read_acl/synchronize > >> :allow > > > > > > OK: then please explain me why there are deny entries in above > > ACL data. > > > > Why should #1 be needed at all? > > That is needed because the mode doesn''t grant executeIf it isn''t granted my the mode, why is there a need to use a "deny" entry?> > Why should #3 be needed at all? > > Mode doesn''t grant write or executeIf it isn''t granted my the mode, why is there a need to use a "deny" entry?> > Why should #5 be needed at all? > > Mode doesn''t grant write or execute, plus we want to take away a bunch > of permissions that aren''t reflected in the mode.If it isn''t granted my the mode, why is there a need to use a "deny" entry? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:> Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote: > > >>>It was created with the set of commands I recently send out when I filed >>>a bugreport against Sun tar. >>> >>>Thr problem with autoconverted ACLs is that you cannot convert them back >>>properly unless you apply a cleanly defines conversion. >>> >> >>All POSIX draft ACLs can be translated to NFSv4 ACLs, but only a small >>subset of NFSv4 ACLs can be translated to POSIX draft ACLs without >>loosing information in the process. > > > ... and all NFSv4 ACLs that have been translated from UFS should allow to > be translated back to UFS correctly. > > The fact that this doesn''t work today is why I did file a bug report..... > > > >>>>A native ZFS ACL would look something like this, with one user ACL entry >>>>prepended to it. >>>> >>>>-rw-r--r--+ 1 marks staff 0 Nov 27 13:44 file.1 >>>> 0:user:maybee:read_data/write_data:allow >>>> 1:owner@:execute:deny >>>> 2:owner@:read_data/write_data/append_data/ >>>> write_xattr/write_attributes >>>> /write_acl/write_owner:allow >>>> 3:group@:write_data/append_data/execute:deny >>>> 4:group@:read_data:allow >>>> 5:everyone@:write_data/append_data/ >>>> write_xattr/execute/write_attributes >>>> /write_acl/write_owner:deny >>>> 6:everyone@:read_data/read_xattr/ >>>> read_attributes/read_acl/synchronize >>>> :allow >>> >>> >>>OK: then please explain me why there are deny entries in above >>>ACL data. >>> >>>Why should #1 be needed at all? >> >>That is needed because the mode doesn''t grant execute > > > If it isn''t granted my the mode, why is there a need to > use a "deny" entry? >Its necessary to maintain POSIX semantics, For example: We have a file with a mode of 0646: That would create an ACL such as: -rw-r--rw- 1 marks staff 0 Nov 27 13:44 file.1 0:owner@:execute:deny 1:owner@:read_data/write_data/append_data/ write_xattr/write_attributes /write_acl/write_owner:allow 2:group@:write_data/append_data/execute:deny 3:group@:read_data:allow 4:everyone@:write_xattr/execute/write_attributes/ write_acl/write_ownerdeny 5:everyone@:read_data/write_data/append_data/ read_xattr/read_attributes /read_acl/synchronize:allow If the process is a meber of group "staff" and they are tring to "write" to the file then we don''t want the process to pick up "write" permissions from the everyone@ entry. Its also a performance win since we don''t have go analyze the entire ACL in order to determine that access shouldn''t be granted.
On Sun, 2005-11-27 at 20:51, Mark Shellenbaum wrote:> The "deny" entries give you a tremendous amount of flexibility. They > allow you to exclude a single user while granting greater permissions to > a large group for example: > > user:fred:read_data/write_data:deny > group:staff:read_data/write_data/execute:allow > <rest of ACL continues> > > Now assuming fred is a member of the group staff then you have just > singled out "fred" from being allowed to read/write or execute the file.In what sense is "deny x" different from the implied deny in "allow everything but x"? (I can see that it''s easier, especially when "everything but x" could be a very long list. But is there something else?) One question, regarding ordering. Does the order in which the ACLs are listed matter? The zfs ACLs have an explicit ordering (you can put new entries anywhere you like, although as I read it you aren''t guaranteed that the order you specify will be preserved); on ufs they tend to be ordered by class then uid. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Peter Tribble wrote:> On Sun, 2005-11-27 at 20:51, Mark Shellenbaum wrote: > > >>The "deny" entries give you a tremendous amount of flexibility. They >>allow you to exclude a single user while granting greater permissions to >>a large group for example: >> >> user:fred:read_data/write_data:deny >> group:staff:read_data/write_data/execute:allow >> <rest of ACL continues> >> >>Now assuming fred is a member of the group staff then you have just >>singled out "fred" from being allowed to read/write or execute the file. > > > In what sense is "deny x" different from the implied deny in > "allow everything but x"? >I think your misunderstanding is in how access control works. See below for a description of that.> (I can see that it''s easier, especially when "everything but x" > could be a very long list. But is there something else?) > > One question, regarding ordering. Does the order in which the ACLs > are listed matter? The zfs ACLs have an explicit ordering (you > can put new entries anywhere you like, although as I read it you > aren''t guaranteed that the order you specify will be preserved); > on ufs they tend to be ordered by class then uid. >Order is very important in ZFS/NFSv4 ACLs. The order that the ACL is stored in is the same order that is used for access control. A user can specify whatever order they want when creating an ACL. When a new file is created ZFS builds its initial ACL in the following order: owner@:deny owner@:allow group@:deny group@:allow everyone@:deny, everyone@:allow If any ACL entries are being inherited then they will be prepended to the above ACL entries. Also, depending on the mode of the file and the permissions of the inherited ACEs extra "deny" entries may be prepended to maintain POSIX semantics. Here are the rules for Access Checking as defined in the NFSv4 protocol specification: To determine if a request succeeds, each nfsace4 entry is processed in order by the server. Only ACEs which have a "who" that matches the requester are considered. Each ACE is processed until all of the bits of the requester''s access have been ALLOWED. Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE is encountered where the requester''s access still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT ACE types do not affect a requester''s access, and instead are for triggering events as a result of a requester''s access attempt. Therefore, all AUDIT and ALARM ACEs are processed until end of the ACL. When the ACL is fully processed, if there are bits in requester''s mask that have not been considered whether the server allows or denies the access is undefined. If there is a mode attribute on the file, then this cannot happen, since the mode''s MODE4_*OTH bits will map to EVERYONE@ ACEs that unambiguously specify the requester''s access.
Seemingly Similar Threads
- zfs acls and MS office applications
- slow directory access, convert_string_internal: Conversion error: Incomplete multibyte sequence
- ZFS Dataset lost structure
- ? NFSv4 and ZFS: removing write_owner attribute does not stop a user changing file group ownership
- Windows permissions and inheritance