zfs discuss - Dec 2005 - First attempt for readble ACLs....

I did already mention that the out put if "ls -v"
is vitually unreadable for NFSv4 ACLs.

Here is my first proposal to make it more readable:

This is the file located on UFS. I created a very simple ACL.

ls -v /var/tmp/file 
-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /var/tmp/file
     0:user::rw-
     1:user:root:rwx            #effective:r--
     2:group::r--               #effective:r--
     3:mask:r--
     4:other:r--


This is the file after it has been copied over to ZFS:

-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/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

As you see, the fact that the ''_'' is contained in every name
causes an optical
separation while the "separator" ''/'' causes an
optical unification.

Here is my first proposal to get to a readable format
using a hacked ls:

./ls -v /pool/file                                                          
-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
     0:owner@:	  rwa--- --mMaA-s:allow
     1:owner@:	  ---x-- --------:deny
     2:user:root: -wax-- ---M-A--:deny
     3:user:root: rwax-- --m-a--s:allow
     4:user:root: ------ ---M-A--:deny
     5:group@:	  -wax-- ---M-A--:deny
     6:group@:	  r----- --m-a--s:allow
     7:group@:	  -wax-- ---M-A--:deny
     8:everyone@: r----- --m-a--s:allow
     9:everyone@: -wax-- ---M-A--:deny

The central permission text is structured this way:

		rwaxdD xXmMaAos
		^^^^^^ ^^^^^^^^
		|||||| ||||||||
		rwaedd rwrwrwcs
		erpxee erererhy
		aipell aiaiaian
		dtecee dtdtdtnc
		 enutt -e-e-eg
		  dtee x-m-A-e
		   e-  axemCA-
		    c  tateLCo
		    h  ttat Lw
		    i  rtda  n
		    l   rad  e
		    d    ta  r
		         at
		          a

The left block is related to the file data and the right
block is related to the file meta data.

Now that you are able to understand the ACL of the file by a single
view, you see that the automated conversion of the ACLs is a complete
mess and needs to be reworked!

Please comment!

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

Hi,

my first attempt to send this mail seems to be lost. So I try to
resend it.


I did already mention that the out put if "ls -v"
is vitually unreadable for NFSv4 ACLs.

Here is my first proposal to make it more readable:

This is the file located on UFS. I created a very simple ACL.

ls -v /var/tmp/file 
-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /var/tmp/file
     0:user::rw-
     1:user:root:rwx            #effective:r--
     2:group::r--               #effective:r--
     3:mask:r--
     4:other:r--


This is the file after it has been copied over to ZFS:

-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/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

As you see, the fact that the ''_'' is contained in every name
causes an optical
separation while the "separator" ''/'' causes an
optical unification.

Here is my first proposal to get to a readable format
using a hacked ls:

./ls -v /pool/file                                                          
-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
     0:owner@:    rwa--- --mMaA-s:allow
     1:owner@:    ---x-- --------:deny
     2:user:root: -wax-- ---M-A--:deny
     3:user:root: rwax-- --m-a--s:allow
     4:user:root: ------ ---M-A--:deny
     5:group@:    -wax-- ---M-A--:deny
     6:group@:    r----- --m-a--s:allow
     7:group@:    -wax-- ---M-A--:deny
     8:everyone@: r----- --m-a--s:allow
     9:everyone@: -wax-- ---M-A--:deny

The central permission text is structured this way:

		rwaxdD xXmMaAos
		^^^^^^ ^^^^^^^^
		|||||| ||||||||
		rwaedd rwrwrwcs
		erpxee erererhy
		aipell aiaiaian
		dtecee dtdtdtnc
		 enutt -e-e-eg
		  dtee x-m-A-e
		   e-  axemCA-
		    c  tateLCo
		    h  ttat Lw
		    i  rtda  n
		    l   rad  e
		    d    ta  r
		         at
		          a

The left block is related to the file data and the right
block is related to the file meta data.

Now that you are able to understand the ACL of the file by a single
view, you see that the automated conversion of the ACLs is a complete
mess and needs to be reworked!

Please comment!

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, Dec 28, 2005 at 03:32:51PM +0100, Joerg Schilling
wrote:
> 
> As you see, the fact that the ''_'' is contained in every
name causes an optical
> separation while the "separator" ''/'' causes an
optical unification.
I don''t agree with this, but to each his own...
> The central permission text is structured this way:
> 
> 		rwaxdD xXmMaAos
> 		^^^^^^ ^^^^^^^^
> 		|||||| ||||||||
> 		rwaedd rwrwrwcs
> 		erpxee erererhy
> 		aipell aiaiaian
> 		dtecee dtdtdtnc
> 		 enutt -e-e-eg
> 		  dtee x-m-A-e
> 		   e-  axemCA-
> 		    c  tateLCo
> 		    h  ttat Lw
> 		    i  rtda  n
> 		    l   rad  e
> 		    d    ta  r
> 		         at
> 		          a
> 
> The left block is related to the file data and the right
> block is related to the file meta data.
There are 17 independent attributes as described in chmod(1).  The above
only shows 14.  Where are the other 3?

I agree that the current output is rather verbose, but at least it''s
understandable.  Being ''readable'' must be balanced against
being
''understandable''.  In particular, the ''ls
-v'' model follows the ppriv(1)
style, where each privilege is spelled out in human readable form, so
that the user doesn''t have to go read a manpage every time the command
is run to translate from the ''readable'' form.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Eric Schrock <eric.schrock at sun.com> wrote:
> On Wed, Dec 28, 2005 at 03:32:51PM +0100, Joerg Schilling wrote:
> > 
> > As you see, the fact that the ''_'' is contained in
every name causes an optical
> > separation while the "separator" ''/''
causes an optical unification.
>
> I don''t agree with this, but to each his own...
>
> > The central permission text is structured this way:
> > 
> > 		rwaxdD xXmMaAos
> > 		^^^^^^ ^^^^^^^^
> > 		|||||| ||||||||
> > 		rwaedd rwrwrwcs
> > 		erpxee erererhy
> > 		aipell aiaiaian
> > 		dtecee dtdtdtnc
> > 		 enutt -e-e-eg
> > 		  dtee x-m-A-e
> > 		   e-  axemCA-
> > 		    c  tateLCo
> > 		    h  ttat Lw
> > 		    i  rtda  n
> > 		    l   rad  e
> > 		    d    ta  r
> > 		         at
> > 		          a
> > 
> > The left block is related to the file data and the right
> > block is related to the file meta data.
>
> There are 17 independent attributes as described in chmod(1).  The above
> only shows 14.  Where are the other 3?
r ->  read_data on Files,   list_directory on Directories
w ->  write_data bei Files, add_file on Directories
a ->  append_data on Files, add_subdirectory on Directories

see /usr/include/sys/acl.h and usr/src/lib/libsec/common/acltext.c

> I agree that the current output is rather verbose, but at least
it''s
> understandable.  Being ''readable'' must be balanced
against being
> ''understandable''.  In particular, the ''ls
-v'' model follows the ppriv(1)
> style, where each privilege is spelled out in human readable form, so
> that the user doesn''t have to go read a manpage every time the
command
> is run to translate from the ''readable'' form.
The big problem is that the currnt ls -v output close to 100% unreadable.

The reason is that it nearly every single element includes a
''_'' that
causes the eye to asume a separation and that the "concatenation" is
done
via ''/'' which does not allow the eye to find a separation.
In addition, the text usually does not fit on single line.

If you like, I can send you the hacked acltext.c 

If you use the modified ls, you will see that the auto-converted
(UFS -> ZFS) ACLs for files look rather braindamaged. Something that
would most likely have been noticed in case that the ls that is available 
inside Sun would produce readable output...

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:
> I did already mention that the out put if "ls -v"
> is vitually unreadable for NFSv4 ACLs.
> 
> Here is my first proposal to make it more readable:
> 
> This is the file located on UFS. I created a very simple ACL.
> 
> ls -v /var/tmp/file 
> -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /var/tmp/file
>      0:user::rw-
>      1:user:root:rwx            #effective:r--
>      2:group::r--               #effective:r--
>      3:mask:r--
>      4:other:r--
> 
> 
> This is the file after it has been copied over to ZFS:
> 
> -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/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
> 
> As you see, the fact that the ''_'' is contained in every
name causes an optical
> separation while the "separator" ''/'' causes an
optical unification.
> 
> Here is my first proposal to get to a readable format
> using a hacked ls:
> 
> ./ls -v /pool/file
> -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
>      0:owner@:	  rwa--- --mMaA-s:allow
>      1:owner@:	  ---x-- --------:deny
>      2:user:root: -wax-- ---M-A--:deny
>      3:user:root: rwax-- --m-a--s:allow
>      4:user:root: ------ ---M-A--:deny
>      5:group@:	  -wax-- ---M-A--:deny
>      6:group@:	  r----- --m-a--s:allow
>      7:group@:	  -wax-- ---M-A--:deny
>      8:everyone@: r----- --m-a--s:allow
>      9:everyone@: -wax-- ---M-A--:deny
> 
> The central permission text is structured this way:
> 
> 		rwaxdD xXmMaAos
> 		^^^^^^ ^^^^^^^^
> 		|||||| ||||||||
> 		rwaedd rwrwrwcs
> 		erpxee erererhy
> 		aipell aiaiaian
> 		dtecee dtdtdtnc
> 		 enutt -e-e-eg
> 		  dtee x-m-A-e
> 		   e-  axemCA-
> 		    c  tateLCo
> 		    h  ttat Lw
> 		    i  rtda  n
> 		    l   rad  e
> 		    d    ta  r
> 		         at
> 		          a
> 
I wanted to add some more readability - I spend a number of minutes
to read the above text and my eyes are still aching :)

                 rwaxdD xXmXaAos
                 ^^^^^^ ^^^^^^^^
                 |||||| |||||||+- sync
                 |||||| ||||||+-- change owner
                 |||||| |||||+--- write ACL
                 |||||| ||||+---- read ACL
                 |||||| |||+----- write metadata
                 |||||| ||+------ read metadata
                 |||||| |+------- write xattr
                 |||||| +-------- read xattr
                 |||||+---------- delete
                 ||||+----------- delete child
                 |||+------------ execute
                 ||+------------- append
                 |+-------------- write
                 +--------------- read
> The left block is related to the file data and the right
> block is related to the file meta data.
> 
> Now that you are able to understand the ACL of the file by a single
> view, you see that the automated conversion of the ACLs is a complete
> mess and needs to be reworked!
> 
> Please comment!
> 
> J?rg
>

On Wed, Dec 28, 2005 at 07:18:21PM +0100, Joerg Schilling
wrote:
> Eric Schrock <eric.schrock at sun.com> wrote:
> 
> 
> r ->  read_data on Files,   list_directory on Directories
> w ->  write_data bei Files, add_file on Directories
> a ->  append_data on Files, add_subdirectory on Directories
> 
> see /usr/include/sys/acl.h and usr/src/lib/libsec/common/acltext.c
OK, so what if you have read_data on a directory, implying that such an
ACL should be inherited on future files created in the directory?  How
would you display that as separate from list_directory?  i.e. you may
have one two directories with list_directory, but only one which has
read_data?  And what about the inherit flags (file_inherit, dir_inherit,
inherit_only, no_propagate)?
> The big problem is that the currnt ls -v output close to 100% unreadable.
> 
> The reason is that it nearly every single element includes a
''_'' that
> causes the eye to asume a separation and that the "concatenation"
is done
> via ''/'' which does not allow the eye to find a
separation.
> In addition, the text usually does not fit on single line.
Once again, I disagree here.  Perhaps a comma separator (a la ppriv)
would be a better choice of separator, though?  I personally like the
''_'' separating words, as it makes things more readable in
plain english.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Joerg Schilling wrote:
> 
> ./ls -v /pool/file
> -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
>      0:owner@:	  rwa--- --mMaA-s:allow
>      1:owner@:	  ---x-- --------:deny
>      2:user:root: -wax-- ---M-A--:deny
>      3:user:root: rwax-- --m-a--s:allow
>      4:user:root: ------ ---M-A--:deny
>      5:group@:	  -wax-- ---M-A--:deny
>      6:group@:	  r----- --m-a--s:allow
>      7:group@:	  -wax-- ---M-A--:deny
>      8:everyone@: r----- --m-a--s:allow
>      9:everyone@: -wax-- ---M-A--:deny
> 
> The central permission text is structured this way:
> 
> 		rwaxdD xXmMaAos
> 		^^^^^^ ^^^^^^^^
> 		|||||| ||||||||
> 		rwaedd rwrwrwcs
> 		erpxee erererhy
> 		aipell aiaiaian
> 		dtecee dtdtdtnc
> 		 enutt -e-e-eg
> 		  dtee x-m-A-e
> 		   e-  axemCA-
> 		    c  tateLCo
> 		    h  ttat Lw
> 		    i  rtda  n
> 		    l   rad  e
> 		    d    ta  r
> 		         at
> 		          a
Yuck, the users will need to have a _legend_ to understand what all of 
the letters mean.  I can see it now, what does capital W mean again.

At least with the current model you don''t need a legend to understand 
it.  Maybe what we need is to just add some whitespace or change some 
delimeters to make it more readable.

Also, how would you represent the inheritance flags?

   -Mark

On Wed, 28 Dec 2005, Cyril Plisko wrote:
> Joerg Schilling wrote:
> > I did already mention that the out put if "ls -v"
> > is vitually unreadable for NFSv4 ACLs.
> >
> > Here is my first proposal to make it more readable:
> >
> > This is the file located on UFS. I created a very simple ACL.
> >
> > ls -v /var/tmp/file
> > -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /var/tmp/file
> >      0:user::rw-
> >      1:user:root:rwx            #effective:r--
> >      2:group::r--               #effective:r--
> >      3:mask:r--
> >      4:other:r--
> >
> >
> > This is the file after it has been copied over to ZFS:
> >
> > -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/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
> >
> > As you see, the fact that the ''_'' is contained in
every name causes an optical
> > separation while the "separator" ''/''
causes an optical unification.
> >
> > Here is my first proposal to get to a readable format
> > using a hacked ls:
> >
> > ./ls -v /pool/file
> > -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
> >      0:owner@:	  rwa--- --mMaA-s:allow
> >      1:owner@:	  ---x-- --------:deny
> >      2:user:root: -wax-- ---M-A--:deny
> >      3:user:root: rwax-- --m-a--s:allow
> >      4:user:root: ------ ---M-A--:deny
> >      5:group@:	  -wax-- ---M-A--:deny
> >      6:group@:	  r----- --m-a--s:allow
> >      7:group@:	  -wax-- ---M-A--:deny
> >      8:everyone@: r----- --m-a--s:allow
> >      9:everyone@: -wax-- ---M-A--:deny
> >
> > The central permission text is structured this way:
> >
> > 		rwaxdD xXmMaAos
> > 		^^^^^^ ^^^^^^^^
> > 		|||||| ||||||||
> > 		rwaedd rwrwrwcs
> > 		erpxee erererhy
> > 		aipell aiaiaian
> > 		dtecee dtdtdtnc
> > 		 enutt -e-e-eg
> > 		  dtee x-m-A-e
> > 		   e-  axemCA-
> > 		    c  tateLCo
> > 		    h  ttat Lw
> > 		    i  rtda  n
> > 		    l   rad  e
> > 		    d    ta  r
> > 		         at
> > 		          a
> >
>
> I wanted to add some more readability - I spend a number of minutes
> to read the above text and my eyes are still aching :)
+1
>                  rwaxdD xXmXaAos
>                  ^^^^^^ ^^^^^^^^
>                  |||||| |||||||+- sync
>                  |||||| ||||||+-- change owner
>                  |||||| |||||+--- write ACL
>                  |||||| ||||+---- read ACL
>                  |||||| |||+----- write metadata
>                  |||||| ||+------ read metadata
>                  |||||| |+------- write xattr
>                  |||||| +-------- read xattr
>                  |||||+---------- delete
>                  ||||+----------- delete child
>                  |||+------------ execute
>                  ||+------------- append
>                  |+-------------- write
>                  +--------------- read
I was about to do the same thing exactly, when I saw your post!
Thanks Cyril!

Regards,

Al Hopper  Logical Approach Inc, Plano, TX.  al at logical-approach.com
           Voice: 972.379.2133 Fax: 972.379.2134  Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005

Eric Schrock wrote:
> Perhaps a comma separator (a la ppriv)
> would be a better choice of separator, though?  I personally like the
> ''_'' separating words, as it makes things more readable in
plain english.

It''s my guess that a comma separator here:
 7:group@:write_data,append_data,execute,write_attributes,write_acl:deny
 8:everyone@:read_data,read_attributes,read_acl,synchronize:allow

looks better than the "/" in the current output.  
 7:group@:write_data/append_data/execute/write_attributes/write_acl:deny
 8:everyone@:read_data/read_attributes/read_acl/synchronize:allow

I''d say: avoid the slash, as we unix users have been trained to see it
as
a concatenator for pathnames.
Using the comma avoids confusion when listing more than one file.

Cheers,
Henk

Mark Shellenbaum schrieb:
> Joerg Schilling wrote:
> 
>>
>> ./ls -v 
>> /pool/file                                                          
>> -rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
>>      0:owner@:      rwa--- --mMaA-s:allow
>>      1:owner@:      ---x-- --------:deny
>>      2:user:root: -wax-- ---M-A--:deny
>>      3:user:root: rwax-- --m-a--s:allow
>>      4:user:root: ------ ---M-A--:deny
>>      5:group@:      -wax-- ---M-A--:deny
>>      6:group@:      r----- --m-a--s:allow
>>      7:group@:      -wax-- ---M-A--:deny
>>      8:everyone@: r----- --m-a--s:allow
>>      9:everyone@: -wax-- ---M-A--:deny
>>
>> The central permission text is structured this way:
>>
>>         rwaxdD xXmMaAos
>>         ^^^^^^ ^^^^^^^^
>>         |||||| ||||||||
>>         rwaedd rwrwrwcs
>>         erpxee erererhy
>>         aipell aiaiaian
>>         dtecee dtdtdtnc
>>          enutt -e-e-eg
>>           dtee x-m-A-e
>>            e-  axemCA-
>>             c  tateLCo
>>             h  ttat Lw
>>             i  rtda  n
>>             l   rad  e
>>             d    ta  r
>>                  at
>>                   a
> 
> 
> Yuck, the users will need to have a _legend_ to understand what all of 
> the letters mean.  I can see it now, what does capital W mean again.
Funny, I never have seen a legend like this:

drwxrwxrwx 1     1001      100       512 Dec  3 14:15  /some/file
^^^^^^^^^^ ^ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^^^^^^^
| |  |  |  |     |        |        |          +------- last access
| |  |  |  |     |        |        +------------------ size
| |  |  |  |     |        +--------------------------- group/gid
| |  |  |  |     +------------------------------------ owner/uid
| |  |  |  +------------------------------------------ number of links
| |  |  +--------------------------------------------- world permissions (1)
| |  +------------------------------------------------ group permissions (1)
| +--------------------------------------------------- owner permissions (1)
+----------------------------------------------------- file type (2)

(1) permissions
     rwx
     ^^^
     ||+----------------------------------------------- execute
     |+------------------------------------------------ write
     +------------------------------------------------- read
[ I skipped the setuid/setgid/sticky part]

(2)
- = regular file
d = directory
l = symbolic link
s = socket
p = named pipe
c = character special file
b = block special file
[...]

at the end of each output of "ls -l".

You can easily memoize above permission flags within a few moments. Maybe
you could use for the meta-part two letter abbreviations:

                  rwaxdD RxWxRmWmRaWaO.S.
                  ^^^^^^ ^^^^^^^^^^^^^^^^
                  |||||| | | | | | | | +- sync
                  |||||| | | | | | | +--- change owner
                  |||||| | | | | | +----- write ACL
                  |||||| | | | | +------- read ACL
                  |||||| | | | +--------- write metadata
                  |||||| | | +----------- read metadata
                  |||||| | +------------- write xattr
                  |||||| +--------------- read xattr
                  |||||+----------------- delete
                  ||||+------------------ delete child
                  |||+------------------- execute
                  ||+-------------------- append
                  |+--------------------- write
                  +---------------------- read

With the capitalized first letter even the two letter abbrevs are easy and 
quickly to scan.
> At least with the current model you don''t need a legend to
understand
> it.  Maybe what we need is to just add some whitespace or change some 
> delimeters to make it more readable.
I don''t like the current output either. It is way too verbose. You
should
know from your own press videos that sometimes more (text) isn''t really
more:

http://www.sun.com/aboutsun/media/



Daniel

Eric Schrock <eric.schrock at sun.com> wrote:
> On Wed, Dec 28, 2005 at 07:18:21PM +0100, Joerg Schilling wrote:
> > Eric Schrock <eric.schrock at sun.com> wrote:
> > 
> > 
> > r ->  read_data on Files,   list_directory on Directories
> > w ->  write_data bei Files, add_file on Directories
> > a ->  append_data on Files, add_subdirectory on Directories
> > 
> > see /usr/include/sys/acl.h and usr/src/lib/libsec/common/acltext.c
>
> OK, so what if you have read_data on a directory, implying that such an
> ACL should be inherited on future files created in the directory?  How
> would you display that as separate from list_directory?  i.e. you may
> have one two directories with list_directory, but only one which has
What you see is a result of the fact that NFSv4 ACLs are a bitwise copy of
the Win-NT-5.x ACLs.

There are only 14 bits although you may see 17 "rights".

If you like to do what you most likely indent with your question, you need
to add two inherit entries to the directory:

-	One with the read_data bit set acording to the intended list behavior
	and use dir_inherit

-	One with the read_data bit set acording to the intended read behavior
	and use file_inherit


> read_data?  And what about the inherit flags (file_inherit, dir_inherit,
> inherit_only, no_propagate)?
I did show this today....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 Thu, Dec 29, 2005 at 08:32:10PM +0100, Joerg Schilling
wrote:
> 
> If you like to do what you most likely indent with your question, you need
> to add two inherit entries to the directory:
> 
> -	One with the read_data bit set acording to the intended list behavior
> 	and use dir_inherit
> 
> -	One with the read_data bit set acording to the intended read behavior
> 	and use file_inherit
Aha, I stand corrected.  Thanks.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Henk Langeveld wrote:
> Eric Schrock wrote:
> 
>> Perhaps a comma separator (a la ppriv)
>> would be a better choice of separator, though?  I personally like the
>> ''_'' separating words, as it makes things more
readable in plain english.
> 
> 
> 
> It''s my guess that a comma separator here:
> 7:group@:write_data,append_data,execute,write_attributes,write_acl:deny
> 8:everyone@:read_data,read_attributes,read_acl,synchronize:allow
> 
> looks better than the "/" in the current output.  
> 7:group@:write_data/append_data/execute/write_attributes/write_acl:deny
> 8:everyone@:read_data/read_attributes/read_acl/synchronize:allow
> 
> I''d say: avoid the slash, as we unix users have been trained to
see it as
> a concatenator for pathnames.
> Using the comma avoids confusion when listing more than one file.
> 
> Cheers,
> Henk
> 
Just to provide a little background on the choice of the "/".

The slash was chosen because we needed a separator and "," was already
taken to separate multiple ACEs.

for example:
  $ chmod \
   A+user:fred:read_data:allow,group:staff:read_data/write_data:allow

We could change the "/" to commas for display purposes, and use the
"/"
when setting an ACL.

Originally we had a "space" separating the ACEs and used commas
between
the permissions, but there were a number of people that complained about 
that since aclfromtext() has historically used a comma for separating 
entries.

   -Mark

On Dec 28, 2005, at 15:32, Joerg Schilling wrote:
> As you see, the fact that the ''_'' is contained in every
name causes
> an optical
> separation while the "separator" ''/'' causes an
optical unification.
 From a user''s perspective, I entirely agree that the output,  
although easily parsable in a script, is not easy to read.

The question is: what is most important - that it is easy for a user  
to see what ACL:s are in effect or that the output is trivial to  
parse in a script? I vote for the former, as long as the latter is  
still possible.

Joerg''s suggestion has great merits in that once you learn the  
letters, seeing which are in effect is very quick. I like that.  
Manually parsing Joerg''s format is a lot quicker for me than the  
current format - if I learn the letters of course (in other words  
it''s "quicker" rather than "easier").

If readability is key (which I tend to think) and we do not want to  
require users learning shorthand letters, then a format like the  
below very rough idea could perhaps be useful:

-rw-r--r--+  1 joerg    300            0 Nov 24 21:45 /pool/file
      0 owner@: read/write/append data, read/write attributes,
          read/write acl, synchronize:allow
      1:owner@: execute:deny
      2:user:root: write/append data, execute, write attributes,  
write acl
          :deny
      3:user:root: read/write/append data, execute, read attributes,
          read acl, synchronize:allow
      4:user:root: write attributes, write acl:deny
      5:group@: write/append data, execute, write attributes, write  
acl:deny
      6:group@: read data, read attributes, read acl, synchronize:allow
      7:group@: write/append data, execute, write attributes,  
write_acl:deny
      8:everyone@: read data, read attributes, read acl,  
synchronize:allow
      9:everyone@: write/append data, execute, write attributes/write  
acl
          :deny

If I am to attempt a motivation behind this suggestion, the above  
format is simpler to use in answering questions like "what am I  
allowed to do with the data". This is because "data",
"acl",
"attributes" etc. are distinct words, surrounded by emptiness (spaces
and commas). Finding "data" in the list is simple, then you look to  
the left to see what you are allowed to do with it. It also looks a  
lot like ordinary written english.

A drawback in the eyes of hardcore UNIX hackers is, of course, the  
blasphemous lack of a one-to-one mapping between an attribute and a  
particular sequence of ASCII bytes in the output.

Had it only been another command than "ls", I would have suggested  
two formats, one like Joerg''s and one like the above. But being
"ls"
that just isn''t possible, and I won''t even think it as I know
there
is currently a death penalty for suggesting yet another "ls" flag.


Just my ?.02,
/Viktor...

On Wed, 2005-12-28 at 20:45, Mark Shellenbaum wrote:
> Yuck, the users will need to have a _legend_ to understand what all of 
> the letters mean.  I can see it now, what does capital W mean again.
Agreed 100% PLEASE PLEASE PLEASE do NOT abbreviate this stuff.

IMO the ls -lv output is a MASSIVE improvement over ls -l or the old
getfacl(1) commands.  It is very obvious what is going on.  I most
certainly do not want to see single letters being used here.

-- 
Darren J Moffat

Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> On Wed, 2005-12-28 at 20:45, Mark Shellenbaum wrote:
>
> > Yuck, the users will need to have a _legend_ to understand what all of
> > the letters mean.  I can see it now, what does capital W mean again.
>
> Agreed 100% PLEASE PLEASE PLEASE do NOT abbreviate this stuff.
What do you mean with that?
> IMO the ls -lv output is a MASSIVE improvement over ls -l or the old
> getfacl(1) commands.  It is very obvious what is going on.  I most
> certainly do not want to see single letters being used here.
The fact that ACL handling is inside ls/chmod is a big improvement because this 
is where people who don''t know the POSIX 1003.1e ACL draft would expect
the
related functionality.

The way ls -lv outputs for NFSv4 ACLs is nice for people who do not understand 
ACLs well (they believe that that may understand the outout). It is also nice 
for automated parsing and for this reason, I believe that it should be the 
_base_ (note that it acannot be used he directly) for a TAR ACL enhancement (*).

For being read by an experienced user, the output from ls -lv is a mess.
An experienced user likes to see something that may be eye-parsed in less than
one minute per file and that allows to quickly identify deviations from other 
files in the same directory.


*) The current NFSv4 format (as well as the UFS ACL format) from sun-tar is
miss-design. It needs to be changed as soon as possible _before_ a non-beta 
version is published.

P.S. I just fixed a few bugs in my ls variant, check 
ftp://ftp.berlios.de/pub/schillix/ for a newer source.


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 Tue, 2006-01-03 at 11:02, Joerg Schilling wrote:
> Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> 
> > On Wed, 2005-12-28 at 20:45, Mark Shellenbaum wrote:
> >
> > > Yuck, the users will need to have a _legend_ to understand what
all of
> > > the letters mean.  I can see it now, what does capital W mean
again.
> >
> > Agreed 100% PLEASE PLEASE PLEASE do NOT abbreviate this stuff.
> 
> What do you mean with that?
I mean I do NOT want to see rwXweRa abbreviations I WANT to see
the words.  Why because it is easier for humans to understand.
> The way ls -lv outputs for NFSv4 ACLs is nice for people who do not
understand
> ACLs well (they believe that that may understand the outout). It is also
nice
> for automated parsing and for this reason, I believe that it should be the 
> _base_ (note that it acannot be used he directly) for a TAR ACL enhancement
(*).
Glad we agree that it is good for novice users.  However parsing the
output of ls(1) is in general not a good idea.

So `ls -lv` is fine then and what you want is `ls -lv --expert-mode`
(but using an appropriate short option letter) ?

-- 
Darren J Moffat

Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> On Tue, 2006-01-03 at 11:02, Joerg Schilling wrote:
> > Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> > 
> > > On Wed, 2005-12-28 at 20:45, Mark Shellenbaum wrote:
> > >
> > > > Yuck, the users will need to have a _legend_ to understand
what all of
> > > > the letters mean.  I can see it now, what does capital W
mean again.
> > >
> > > Agreed 100% PLEASE PLEASE PLEASE do NOT abbreviate this stuff.
> > 
> > What do you mean with that?
>
> I mean I do NOT want to see rwXweRa abbreviations I WANT to see
> the words.  Why because it is easier for humans to understand.
Well then please make a proposal that uses words _and_ is readable....
The current implementation is not readable.

As a hint: 

-	Make sure that one entry fits on one line of a 80 character screen

-	Make sure that the different ascertainable in one single glance

> > The way ls -lv outputs for NFSv4 ACLs is nice for people who do not
understand
> > ACLs well (they believe that that may understand the outout). It is
also nice
> > for automated parsing and for this reason, I believe that it should be
the
> > _base_ (note that it acannot be used he directly) for a TAR ACL
enhancement (*).
>
> Glad we agree that it is good for novice users.  However parsing the
> output of ls(1) is in general not a good idea.
I am not sure if you know this, but the ACL output from ls is created
by acltotext() from within libsec. Nobody will like to parse the ls output for 
ACLs but ad the output is identical to other outpout, you could.
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 Tue, 2006-01-03 at 13:18, Joerg Schilling wrote:
> Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> 
> > On Tue, 2006-01-03 at 11:02, Joerg Schilling wrote:
> > > Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> > > 
> > > > On Wed, 2005-12-28 at 20:45, Mark Shellenbaum wrote:
> > > >
> > > > > Yuck, the users will need to have a _legend_ to
understand what all of
> > > > > the letters mean.  I can see it now, what does capital
W mean again.
> > > >
> > > > Agreed 100% PLEASE PLEASE PLEASE do NOT abbreviate this
stuff.
> > > 
> > > What do you mean with that?
> >
> > I mean I do NOT want to see rwXweRa abbreviations I WANT to see
> > the words.  Why because it is easier for humans to understand.
> 
> Well then please make a proposal that uses words _and_ is readable....
> The current implementation is not readable.
My proposal is leave it alone.  It works for me.
> As a hint: 
> 
> -	Make sure that one entry fits on one line of a 80 character screen
> 
> -	Make sure that the different ascertainable in one single glance
but I don''t have a requirement for either of those so I''m not
going to
make any such proposal.

The whole point of my message was that I didn''t see a problem with the
current implementation but I saw major issues with anything that
abbreviates down to single letters.

I don''t mind if there is a mode where abbreviations are used but I
think
the full words are a major enhancement and that should be the default
case for -v.

-- 
Darren J Moffat

Viktor Fougstedt <viktor at chalmers.se> wrote:
> A drawback in the eyes of hardcore UNIX hackers is, of course, the  
> blasphemous lack of a one-to-one mapping between an attribute and a  
> particular sequence of ASCII bytes in the output.
>
> Had it only been another command than "ls", I would have
suggested
> two formats, one like Joerg''s and one like the above. But being
"ls"
> that just isn''t possible, and I won''t even think it as I
know there
> is currently a death penalty for suggesting yet another "ls"
flag.
This is what I did implement in ls:

ftp://ftp.berlios.de/pub/schillix/ls.tar.bz2

ls -v (Sun format readable for dummies)
ls -V (Expert format)

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

Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> > Well then please make a proposal that uses words _and_ is readable....
> > The current implementation is not readable.
>
> My proposal is leave it alone.  It works for me.
If only one person is happy with the current output, it does not seem to be
satisfactory.
> > As a hint: 
> > 
> > -	Make sure that one entry fits on one line of a 80 character screen
> > 
> > -	Make sure that the different ascertainable in one single glance
>
> but I don''t have a requirement for either of those so I''m
not going to
> make any such proposal.
>
> The whole point of my message was that I didn''t see a problem with
the
> current implementation but I saw major issues with anything that
> abbreviates down to single letters.
If you usually never check ACLs it may be OK for you, but why should we make 
this the gauge for power users?

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, 2006-01-04 at 15:53, Joerg Schilling wrote:
> Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> 
> > > Well then please make a proposal that uses words _and_ is
readable....
> > > The current implementation is not readable.
> >
> > My proposal is leave it alone.  It works for me.
> 
> If only one person is happy with the current output, it does not seem to be
> satisfactory.
and of course you have proof that I''m the only one person right!

Remember the old adage that you are about 10 times more likely to tell
someone about something you don''t like than something you do.

Log an a RFE, provide the code and lets see where it goes (yes I know
you have done the later).  Note as I''ve said several times already
I''m
not against an "expert" mode as long as it a verbose one is also
available (given that not even -l is the default in ls(1) it is actually
silly to talk about wither or not wordy verbose or abbreviated verbose
is the "default").


-- 
Darren J Moffat

> This is what I did implement in ls:
> 
> ftp://ftp.berlios.de/pub/schillix/ls.tar.bz2
> 
> ls -v (Sun format readable for dummies)
I don''t consider myself a dummy, but perhaps age has
decreased my tolerance for gratuitous brevity.
> ls -V (Expert format)
I know I''ll never remember what all of the columns
represent.  But perhaps people using old ADDS
terminals will appreciate this mode :-)

[IIRC, one of the UNIX old-timers (Kernigan?) once 
said that adding any more options to ls should be
illegal... right before ACLs came out :-)]
 -- richard
This message posted from opensolaris.org

Richard Elling schrieb:
>>This is what I did implement in ls:
>>
>>ftp://ftp.berlios.de/pub/schillix/ls.tar.bz2
>>
>>ls -v (Sun format readable for dummies)
> 
> I don''t consider myself a dummy, but perhaps age has
> decreased my tolerance for gratuitous brevity.
For me, I don''t need this mode. A shorthand display - as J?rg proposed
-
should be as easily parseable than this mess - and much faster to scan for the 
human eye.

>>ls -V (Expert format)
+1

> I know I''ll never remember what all of the columns
> represent.  But perhaps people using old ADDS
> terminals will appreciate this mode :-)
You need a terminal at least 200 characters wide to avoid additional line 
wraps. If someone is experienced enough to use a shell and type "ls"
he should
be able to quickly memoize the abbrevs. If not - he still has nautilus (when 
it''s patched someday).


Even Windows has shortened ACL descriptions:

C:\WINDOWS\System32> cacls .
C:\WINDOWS\system32 VORDEFINIERT\Benutzer:R
                     VORDEFINIERT\Benutzer:(OI)(CI)(IO)(Beschr?nkter Zugriff:)
                                                       GENERIC_READ
                                                       GENERIC_EXECUTE

                     VORDEFINIERT\Hauptbenutzer:C
                     VORDEFINIERT\Hauptbenutzer:(OI)(CI)(IO)C
                     VORDEFINIERT\Administratoren:F
                     VORDEFINIERT\Administratoren:(OI)(CI)(IO)F
                     NT-AUTORIT?T\SYSTEM:F
                     NT-AUTORIT?T\SYSTEM:(OI)(CI)(IO)F
                     VORDEFINIERT\Administratoren:F
                     ERSTELLER-BESITZER:(OI)(CI)(IO)F

Ok, cacls doesn''t provide a interface for all possible ACL bits (only
the most
common ones). Only if you apply unusual ACL settings cacls gets more verbose 
(in the example above below "Beschr?nkter Zugriff"). XCACLS[1] has
even more
predefined ACL flags (each one character wide). If you want a really messy 
output you can try SUBINACL[2] instead. And even this tool has a /noverbose
flag:

C:\Programme\Resource Kit>subinacl /noverbose /file c:\windows\system32

=========================+File c:\windows\system32
=========================/control=0x1400
/owner             =vordefiniert\administratoren
/primary group     =system
/audit ace count   =0
/perm. ace count   =10
/pace =vordefiniert\benutzer  Type=0x0 Flags=0x0 AccessMask=0x1200a9
/pace =vordefiniert\benutzer  Type=0x0 Flags=0xb AccessMask=0xa0000000
/pace =vordefiniert\hauptbenutzer  Type=0x0 Flags=0x0 AccessMask=0x1301bf
/pace =vordefiniert\hauptbenutzer  Type=0x0 Flags=0xb AccessMask=0xe0010000
/pace =vordefiniert\administratoren  Type=0x0 Flags=0x0 AccessMask=0x1f01ff
/pace =vordefiniert\administratoren  Type=0x0 Flags=0xb AccessMask=0x10000000
/pace =system  Type=0x0 Flags=0x0 AccessMask=0x1f01ff
/pace =system  Type=0x0 Flags=0xb AccessMask=0x10000000
/pace =vordefiniert\administratoren  Type=0x0 Flags=0x0 AccessMask=0x1f01ff
/pace =ersteller-besitzer  Type=0x0 Flags=0xb AccessMask=0x10000000


Granted, this option is only useful in scripts.




Daniel


[1] 
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/xcacls-o.asp
[2] 
http://www.microsoft.com/downloads/details.aspx?familyid=E8BA3E56-D8FE-4A91-93CF-ED6985E3927B

On Tue, 2006-01-03 at 11:28, Darren J Moffat wrote:
> My proposal is leave it alone.  It works for me.
it does not work for me - for me, long lists of access rights are
utterly impenetrable.  I think the readability problem for access rights
comes from a combination of the very large number of individual rights
and the variable width encoding of each right which makes it hard to
predict *where* a given right would appear in the list.  And if a right
is missing from a long list, it''s also hard to spot.

I don''t think you need a single-character encoding for each right, but
a
more compact and regular encoding seems possible.

					- Bill

As a sysadmin, I like Daniel''s (drexl) proposal above, where the
"regular" ACLs use one letter, and the "extended" use two.
This maintains quick parsability, while keeping the two "levels" (for
lack of a better way for me to say it--someone will correct me, I''m
sure) visually clear. Having two letters helps the mnemonics (and therefore, the
clarity). This should be relatively easy for people to learn and get used to.

While the verbose mode may be usable to some people when in short listings, it
quickly becomes messy, and gets hard to see where one file ends and the next
starts. Trying to keep the information down to one line per file is important
for clarity. (If the filename is 300 characters, there''s _nothing_ we
can do to help matters.) The verbosity of the initial listing, while seemingly
useful, quickly becomes a detriment that counteracts the original usefulness. I
agree with Jeorg in the visual unification/separation analysis. While I have
little desire to remember more arcana, I need something I can read--I cannot
read the original listing. Daniel''s suggestion agrees with
Jeorg''s analysis while, I feel, minimizing the opaqueness.

In short, I think the two-letter mnemonics are a good compromise to the
"full listing" versus "bare minimum" impasse.

rheilke
This message posted from opensolaris.org

I think there''s some merit in a two-letter extended format for "ls
-lV" listings - at the very least it is consistant with the existing
"ls -l" output.

One question I''ll put to you - should it be "RdRaRm" or
"DrArMr" ?
i.e. should the "read" be capitalised or the
"data/acl/metadata" part ?  verb or noun?

With the longer style output, I''d like to float a different format
completely:

owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
owner@::     deny=file:x,,,,
user:root:      deny=file:wax,attr:w,acl:w,,
user:root:     allow=file:rwax,attr:r,acl:r,sync,
user:root:      deny=file:,attr:w,acl:w,,
group@::    deny=file:wax,attr:w,acl:w,,
group@::   allow=file:r,attr:r,acl:r,sync,
group@::    deny=file:wax,attr:w,acl:w
everyone@::   allow=file:r,attr:r,acl:r,sync,
everyone@::    deny=file:wax,attr:w,acl:w,,

..perhaps the ''='' should also be a '':''...

but the idea is that the output is verbose without there being too much text. 
The extra :''s and ,''s are there to maintain a regular output
format for tools that will parse the output - i.e. a username or groupname is
always in the 2nd column, a missing acl is an empty field rather than missing,
etc.

Looking at the current format, I''m just dreading having to actually
type it in to use it on the command line - the chmod command is going to be a
seriously long type at my shell prompt!

Darren
This message posted from opensolaris.org

On Jan 5, 2006, at 01:29, Darren Reed wrote:
> With the longer style output, I''d like to float a different format
> completely:
>
> owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
> owner@::     deny=file:x,,,,
> user:root:      deny=file:wax,attr:w,acl:w,,
> user:root:     allow=file:rwax,attr:r,acl:r,sync,
> user:root:      deny=file:,attr:w,acl:w,,
[...]

To me, being an "end-user" sysadmin, this seems like the absolutely  
best format suggested so far! Readable, parsable and understandable.  
Short and distinct, yet not cryptic.


Regards,
/Viktor...

> > owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
> > owner@::     deny=file:x,,,,
> > user:root:      deny=file:wax,attr:w,acl:w,,
> > user:root:     allow=file:rwax,attr:r,acl:r,sync,
> > user:root:      deny=file:,attr:w,acl:w,,
> [...]
> 
> To me, being an "end-user" sysadmin, this seems like the
absolutely
> best format suggested so far! Readable, parsable and understandable.  
> Short and distinct, yet not cryptic.
I like it too -- or at least, something of this general flavor.

The current long form really is too long, and other proposed short
forms really are too short -- they look like /etc/termcap entries.
This one strikes a nice balance.

Jeff

Richard Elling <Richard.Elling at Sun.com> wrote:
> > This is what I did implement in ls:
> > 
> > ftp://ftp.berlios.de/pub/schillix/ls.tar.bz2
> > 
> > ls -v (Sun format readable for dummies)
>
> I don''t consider myself a dummy, but perhaps age has
> decreased my tolerance for gratuitous brevity.
Even an expert will not be able to read it, this is why I did call
it dummy mode.

Verify by: create 100 files in a dir and now try to find one file
that does not have a specific permission set from the ls -v outout 
for that dir.

> > ls -V (Expert format)
>
> I know I''ll never remember what all of the columns
> represent.  But perhaps people using old ADDS
> terminals will appreciate this mode :-)
As long as Sun does not allow Solaris sources to take advantage 
of even 132 character wide screens (cstyle requires 80 chars),  
I cannot see why a format that needs more than 200 char wide
screens in otder to become halfway readable.

> [IIRC, one of the UNIX old-timers (Kernigan?) once 
> said that adding any more options to ls should be
> illegal... right before ACLs came out :-)]
He did not know star which has > 150 basic options :-)

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

Viktor Fougstedt <viktor at chalmers.se> wrote:
>
> On Jan 5, 2006, at 01:29, Darren Reed wrote:
>
> > With the longer style output, I''d like to float a different
format
> > completely:
> >
> > owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
> > owner@::     deny=file:x,,,,
> > user:root:      deny=file:wax,attr:w,acl:w,,
> > user:root:     allow=file:rwax,attr:r,acl:r,sync,
> > user:root:      deny=file:,attr:w,acl:w,,
> [...]
>
> To me, being an "end-user" sysadmin, this seems like the
absolutely
> best format suggested so far! Readable, parsable and understandable.  
> Short and distinct, yet not cryptic.
To me this looks like a really nice alternate format for setting
ACLs via chmod but for readability, I would prefer a format that is close to
what I proposed.

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

Jeff Bonwick <bonwick at zion.eng.sun.com> wrote:
> > > owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
> > > owner@::     deny=file:x,,,,
> > > user:root:      deny=file:wax,attr:w,acl:w,,
> > > user:root:     allow=file:rwax,attr:r,acl:r,sync,
> > > user:root:      deny=file:,attr:w,acl:w,,
> > [...]
> > 
> > To me, being an "end-user" sysadmin, this seems like the
absolutely
> > best format suggested so far! Readable, parsable and understandable.  
> > Short and distinct, yet not cryptic.
>
> I like it too -- or at least, something of this general flavor.
>
> The current long form really is too long, and other proposed short
> forms really are too short -- they look like /etc/termcap entries.
> This one strikes a nice balance.
There is a difference: /etc/termcap does not need dayly maintenance
so you will forget about the meaning but you always could use a
termcap decompiler like my "cap" program to list something like:

tbuf: ''x1|xterm|vs100|xterm terminal emulator (X Window
System)''
''am'' -> TRUE            terminal has automatic margins
''xn'' -> TRUE            newline ignored after 80 cols
(concept)
''km'' -> TRUE            Has a meta key, sets msb high
''mi'' -> TRUE            safe to move while in insert mode
''ms'' -> TRUE            safe to move while in standout mode
''co'' -> 80              number of columns in a line
''li'' -> 65              number of lines on screen or page
''cs'' -> ''\E[%i%d;%dr''   change region to
line #1 to line #2 (P)
''ct'' -> ''\E[3k''         clear all tab
stops (P)
....

and terminfo is worse than termcap.....

The format above has the advantage of being memorizable (sou you may use it
as input format) but you still need to "read" it instead of just
having a "look
at it" as possible with my proposal.

For all people who like to rate the usability, I strongly recommend to 
use my source 

	ftp://ftp.berlios.de/pub/schillix/ls.tar.bz2

and play at least 5 minutes with the ls -V output of the program. I am sure this
will prove that it is easy to memoryze the meeaning of the output. All people
who
did have been much more satisfied than with ls -v output.



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

Darren Reed wrote:
> I think there''s some merit in a two-letter extended format for
"ls -lV" listings - at the very least it is consistant with the
existing "ls -l" output.
> 
> One question I''ll put to you - should it be "RdRaRm" or
"DrArMr" ?
> i.e. should the "read" be capitalised or the
"data/acl/metadata" part ?  verb or noun?
> 
> With the longer style output, I''d like to float a different format
completely:
> 
> owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
> owner@::     deny=file:x,,,,
> user:root:      deny=file:wax,attr:w,acl:w,,
> user:root:     allow=file:rwax,attr:r,acl:r,sync,
> user:root:      deny=file:,attr:w,acl:w,,
> group@::    deny=file:wax,attr:w,acl:w,,
> group@::   allow=file:r,attr:r,acl:r,sync,
> group@::    deny=file:wax,attr:w,acl:w
> everyone@::   allow=file:r,attr:r,acl:r,sync,
> everyone@::    deny=file:wax,attr:w,acl:w,,
> 
Its not clear from your example how the following permissions would be 
represented: write_owner, delete and delete_child.

Also, how would you use this in a chmod?  There is a requirement that 
the mode argument be a single argument.  With all of the "," that may
be
a problem.

Lets look at an example of adding two ACEs to a files current ACL

chmod
A+owner@::allow=file:rwa,attr:acl,sync,user:barney:allow=file:rwx,attr:,acl:,sync
   file

That would be really messy.

    -Mark

> ..perhaps the ''='' should also be a
'':''...
> 
> but the idea is that the output is verbose without there being too much
text.  The extra :''s and ,''s are there to maintain a regular
output format for tools that will parse the output - i.e. a username or
groupname is always in the 2nd column, a missing acl is an empty field rather
than missing, etc.
> 
> Looking at the current format, I''m just dreading having to
actually type it in to use it on the command line - the chmod command is going
to be a seriously long type at my shell prompt!
> 
> Darren
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:
> Its not clear from your example how the following permissions would be 
> represented: write_owner, delete and delete_child.
>
> Also, how would you use this in a chmod?  There is a requirement that 
> the mode argument be a single argument.  With all of the "," that
may be
> a problem.
>
> Lets look at an example of adding two ACEs to a files current ACL
>
> chmod
>
A+owner@::allow=file:rwa,attr:acl,sync,user:barney:allow=file:rwx,attr:,acl:,sync
>    file
note that chmod currently allows to update a comma separated list if ACLs.
So using '','' to separate parts of a single ACE does not give
you all of the
previous features.


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

Mark Shellenbaum wrote:
> Darren Reed wrote:
> 
>> I think there''s some merit in a two-letter extended format for
"ls
>> -lV" listings - at the very least it is consistant with the
existing
>> "ls -l" output.
>>
>> One question I''ll put to you - should it be "RdRaRm"
or "DrArMr" ?
>> i.e. should the "read" be capitalised or the
"data/acl/metadata" part
>> ?  verb or noun?
>>
>> With the longer style output, I''d like to float a different
format
>> completely:
>>
>> owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
>> owner@::     deny=file:x,,,,
>> user:root:      deny=file:wax,attr:w,acl:w,,
>> user:root:     allow=file:rwax,attr:r,acl:r,sync,
>> user:root:      deny=file:,attr:w,acl:w,,
>> group@::    deny=file:wax,attr:w,acl:w,,
>> group@::   allow=file:r,attr:r,acl:r,sync,
>> group@::    deny=file:wax,attr:w,acl:w
>> everyone@::   allow=file:r,attr:r,acl:r,sync,
>> everyone@::    deny=file:wax,attr:w,acl:w,,
>>
> 
> Its not clear from your example how the following permissions would be 
> represented: write_owner, delete and delete_child.
> 
Also, how would the various inheritance flags be displayed?

> Also, how would you use this in a chmod?  There is a requirement that 
> the mode argument be a single argument.  With all of the "," that
may be
> a problem.
> 
> Lets look at an example of adding two ACEs to a files current ACL
> 
> chmod
>
A+owner@::allow=file:rwa,attr:acl,sync,user:barney:allow=file:rwx,attr:,acl:,sync
>    file
> 
> That would be really messy.
> 
>     -Mark
> 
> 
>> ..perhaps the ''='' should also be a
'':''...
>>
>> but the idea is that the output is verbose without there being too 
>> much text.  The extra :''s and ,''s are there to
maintain a regular
>> output format for tools that will parse the output - i.e. a username 
>> or groupname is always in the 2nd column, a missing acl is an empty 
>> field rather than missing, etc.
>>
>> Looking at the current format, I''m just dreading having to
actually
>> type it in to use it on the command line - the chmod command is going 
>> to be a seriously long type at my shell prompt!
>>
>> Darren
>> This message posted from opensolaris.org
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> 
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

> > owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
> > owner@::     deny=file:x,,,,
> > user:root:      deny=file:wax,attr:w,acl:w,,
> > user:root:     allow=file:rwax,attr:r,acl:r,sync,
> > user:root:      deny=file:,attr:w,acl:w,,
> > group@::    deny=file:wax,attr:w,acl:w,,
> > group@::   allow=file:r,attr:r,acl:r,sync,
> > group@::    deny=file:wax,attr:w,acl:w
> > everyone@::   allow=file:r,attr:r,acl:r,sync,
> > everyone@::    deny=file:wax,attr:w,acl:w,, 
> 
> Its not clear from your example how the following permissions would be 
> represented: write_owner, delete and delete_child.
Following on from the above theme:
file:rwaxd,named:rw,attr:rw,acl:rw,,chown,sync,
dir:rwad,named:rw,attr:rw,acl:rw,inherit:fdon,chown,sync,rm

* from reading RFC 3530, inheritence is for directories only
* you can''t execute directories
* chown = write owner
* rm = delete child
* the ''d'' next to file/dir applies to deleting that object

I thought about "owner" instead of "chown", but this output
is for people
who have used unix and understand chmod/chown and it seems to me
that using "chown" instead of "owner" is a better choice. 
Similarly for
"rm", although I do wonder if there''s a sufficient
distinction between
having "rm" and ''d'' next to the "dir:".

I''m not sure that "named" and "attr" are
distinctive enough, but the
current distinction is "read_xattr" and "read_attributes". 
Clearly some
of the blame here needs to fall upon the people desiging NFSv4 and the
accompanying RFC for not choosing sufficiently distinctive names here.
> Also, how would you use this in a chmod?  There is a requirement that 
> the mode argument be a single argument.  With all of the "," that
may be
> a problem.
> 
> Lets look at an example of adding two ACEs to a files
> current ACL
> 
> chmod
>
A+owner@::allow=file:rwa,attr:acl,sync,user:barney:allow=file:rwx,attr:,acl:,sync
file
The empty spacing for ,''s shouldn''t be required for chmod.
Optional, yes, but not required.  The use above is to maintain output formatting
in a manner that is easy to parse - this isn''t an issue for input, such
as with chmod.
Second, I think you need to make some logical assumptions about what the input
means.  For example, you have "attr:," to represent no permissions for
xattr.
If there is no "attr:" then there are none applied (i.e. it has the
same impact as
the empty "attr:").  So the above could also be:

chmod A+owner@::allow=file:rwa,sync,user:barney:allow=file:rwx,sync file

What I don''t like here is "sync,user:...".  That''s
not clear enough.
Maybe we should be using + instead?

chmod A+owner@::allow=file:rwa,sync+user:barney:allow=file:rwx,sync file

Can we then go on to do "chmod A+user:foo..-user:barney:.." ?

i.e. add an acl for user:foo and remove one for user:barney?

Darren
This message posted from opensolaris.org

I''d like to make some fresh proposals.

(1) -v and -V

As has been suggested before, let''s stick with the idea of leaving  
"ls -lv" as-is, and having "ls -lV" be an abbreviated mode.

(2) Try for some uniformity across OS''s

AIX already has a scheme for single-letter abbreviations of NFSv4 ACL  
access masks, and two-letter abbreviations for flags.  Linux has  
something similar, but currently different from AIX, and it''s not  
generally released yet.

So if possible, let''s try to get the Linux developers to adopt
IBM''s
AIX scheme, and we''ll join the consensus.  But either way,
let''s not
invent a third scheme for single-letter abbreviations.

The AIX scheme can be found on the web; email me if you''re curious  
and you have trouble finding it.

(3) Unique abbreviations, displayed positionally

When displaying ACL data, let''s use a positional notation, but with  
unique letters.  Jorg''s proposal reuses some letters, e.g.
"a".  I
would propose that we make the abbreviations unique.  AIX''s scheme  
and the current Linux scheme both have unique abbreviations.

Positional display, as Jorg pointed out, has the advantage of  
allowing one to efficiently scan for specific things.  For example,  
one could easily look through an ACL to see if any of the ACEs  
specify WRITE_OWNER.

For setting or modifying ACLs, chmod could potentially accept either  
the long or the abbreviated form.  By using unique (position- 
independent) abbreviations, chmod could also accept the abbreviated  
form whether it was positional or crunched into non-positional.  For  
example, chmod could accept any of these three sets of access_mask bits:

read_data/execute (ls -lv output)
r--x-------- (ls -lV output)
rx (never output by ls, but easier to type from scratch)

- Sam

Here''s some example output from the proposed scheme.  "ls
-lv" is
copied from a real ZFS file system, "ls -lV" is done by hand; any  
errors are mine.  I prepended spaces to the "who" entries for owner@  
and group@, to make them line up with everyone at .  I haven''t put too
much thought into the column ordering; for the "ls -lV" sample,  
here''s the order I used.

- Sam

read_data,write_data,append_data,execute,
read_attributes,write_attributes,read_xattr,write_xattr,
delete,delete_child
read_acl,write_acl,write_owner,synchronize

% /usr/bin/ls -lv foo
-rw-r--r--   1 nobody4  root           0 Dec 19 15:29 foo
      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_data/append_data/write_xattr/execute/ 
write_attributes
          /write_acl/write_owner:deny
      5:everyone@:read_data/read_xattr/read_attributes/read_acl/ 
synchronize
          :allow

% /usr/bin/ls -lV foo
-rw-r--r--   1 nobody4  root           0 Dec 19 15:29 foo
      0:   owner@:---x--------:deny
      1:   owner@:rwp--A-W---Co-:allow
      2:   group@:-wpx----------:deny
      3:   group@:r-------------:allow
      4:everyone@:-wpx-A-W---Co-:deny
      5:everyone@:r---a-R---c--s:allow

On Jan 6, 2006, at 12:29 AM, Sam Falkner wrote:
> I''d like to make some fresh proposals.
>
> (1) -v and -V
>
> As has been suggested before, let''s stick with the idea of leaving
> "ls -lv" as-is, and having "ls -lV" be an abbreviated
mode.
>
> (2) Try for some uniformity across OS''s
>
> AIX already has a scheme for single-letter abbreviations of NFSv4  
> ACL access masks, and two-letter abbreviations for flags.  Linux  
> has something similar, but currently different from AIX, and it''s
> not generally released yet.
>
> So if possible, let''s try to get the Linux developers to adopt  
> IBM''s AIX scheme, and we''ll join the consensus.  But
either way,
> let''s not invent a third scheme for single-letter abbreviations.
>
> The AIX scheme can be found on the web; email me if you''re curious
> and you have trouble finding it.
>
> (3) Unique abbreviations, displayed positionally
>
> When displaying ACL data, let''s use a positional notation, but
with
> unique letters.  Jorg''s proposal reuses some letters, e.g.
"a".  I
> would propose that we make the abbreviations unique.  AIX''s scheme
> and the current Linux scheme both have unique abbreviations.
>
> Positional display, as Jorg pointed out, has the advantage of  
> allowing one to efficiently scan for specific things.  For example,  
> one could easily look through an ACL to see if any of the ACEs  
> specify WRITE_OWNER.
>
> For setting or modifying ACLs, chmod could potentially accept  
> either the long or the abbreviated form.  By using unique (position- 
> independent) abbreviations, chmod could also accept the abbreviated  
> form whether it was positional or crunched into non-positional.   
> For example, chmod could accept any of these three sets of  
> access_mask bits:
>
> read_data/execute (ls -lv output)
> r--x-------- (ls -lV output)
> rx (never output by ls, but easier to type from scratch)
>
> - Sam
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Sam Falkner <Sam.Falkner at Sun.COM> wrote:
> I''d like to make some fresh proposals.
>
> (1) -v and -V
>
> As has been suggested before, let''s stick with the idea of leaving
> "ls -lv" as-is, and having "ls -lV" be an abbreviated
mode.
OK, so this proposal seems to accepted.
> (2) Try for some uniformity across OS''s
>
> AIX already has a scheme for single-letter abbreviations of NFSv4 ACL  
> access masks, and two-letter abbreviations for flags.  Linux has  
What do you/they call "access masks" and what do they call
"flags"?
> something similar, but currently different from AIX, and it''s not
> generally released yet.
Well, my hack is available to everyone who is interested.
> So if possible, let''s try to get the Linux developers to adopt
IBM''s
> AIX scheme, and we''ll join the consensus.  But either way,
let''s not
> invent a third scheme for single-letter abbreviations.
>
> The AIX scheme can be found on the web; email me if you''re curious
> and you have trouble finding it.
I was able to find fragements that contain ACL strings from AIX but no 
complete documentation similar to what I did send for my hacked ls.

Could you point me to the documentation?

Do you have a hacked ls that behaves the intended way?

Note that my ls is ready for testing at:

	ftp://ftp.berlios.de/pub/schillix/ls.tar.bz2


> (3) Unique abbreviations, displayed positionally
>
> When displaying ACL data, let''s use a positional notation, but
with
> unique letters.  Jorg''s proposal reuses some letters, e.g.
"a".  I
> would propose that we make the abbreviations unique.  AIX''s scheme
> and the current Linux scheme both have unique abbreviations.
So let us check the documentation and discuss it.
> Positional display, as Jorg pointed out, has the advantage of  
> allowing one to efficiently scan for specific things.  For example,  
> one could easily look through an ACL to see if any of the ACEs  
> specify WRITE_OWNER.
>
> For setting or modifying ACLs, chmod could potentially accept either  
> the long or the abbreviated form.  By using unique (position- 
> independent) abbreviations, chmod could also accept the abbreviated  
> form whether it was positional or crunched into non-positional.  For  
> example, chmod could accept any of these three sets of access_mask bits:
>
> read_data/execute (ls -lv output)
> r--x-------- (ls -lV output)
> rx (never output by ls, but easier to type from scratch)
If it is possible to find such a coding.... I did not get the right ideas
for position independend coding.

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

Darren Reed wrote:
>>>owner@::    allow=file:rwa,attr:rw,acl:rw,sync,
>>>owner@::     deny=file:x,,,,
>>>user:root:      deny=file:wax,attr:w,acl:w,,
>>>user:root:     allow=file:rwax,attr:r,acl:r,sync,
>>>user:root:      deny=file:,attr:w,acl:w,,
>>>group@::    deny=file:wax,attr:w,acl:w,,
>>>group@::   allow=file:r,attr:r,acl:r,sync,
>>>group@::    deny=file:wax,attr:w,acl:w
>>>everyone@::   allow=file:r,attr:r,acl:r,sync,
>>>everyone@::    deny=file:wax,attr:w,acl:w,, 
>>
>>Its not clear from your example how the following permissions would be 
>>represented: write_owner, delete and delete_child.
> 
> 
> Following on from the above theme:
> file:rwaxd,named:rw,attr:rw,acl:rw,,chown,sync,
> dir:rwad,named:rw,attr:rw,acl:rw,inherit:fdon,chown,sync,rm
> 
This is starting to look a bit complicated.  You have permissions mixed 
in with inheritance.  This is going to confuse more people than it 
helps.  Think about the novice user that has a hard time understanding 
the difference between what file vs attr vs dir means.  Sure a seasoned 
sysadmin will understand the difference, but what about a casual user.

This is also going to fail the test of being able to quickly scan a 
listing for a given permission.
> * from reading RFC 3530, inheritence is for directories only
> * you can''t execute directories
> * chown = write owner
> * rm = delete child
> * the ''d'' next to file/dir applies to deleting that
object
> 
> I thought about "owner" instead of "chown", but this
output is for people
> who have used unix and understand chmod/chown and it seems to me
> that using "chown" instead of "owner" is a better
choice.  Similarly for
> "rm", although I do wonder if there''s a sufficient
distinction between
> having "rm" and ''d'' next to the
"dir:".
> 
> I''m not sure that "named" and "attr" are
distinctive enough, but the
> current distinction is "read_xattr" and
"read_attributes".  Clearly some
> of the blame here needs to fall upon the people desiging NFSv4 and the
> accompanying RFC for not choosing sufficiently distinctive names here.
> 
> 
>>Also, how would you use this in a chmod?  There is a requirement that 
>>the mode argument be a single argument.  With all of the ","
that may be
>>a problem.
>>
>>Lets look at an example of adding two ACEs to a files
>>current ACL
>>
>>chmod
>>A+owner@::allow=file:rwa,attr:acl,sync,user:barney:allow=file:rwx,attr:,acl:,sync
file
> 
> 
> The empty spacing for ,''s shouldn''t be required for
chmod.
> Optional, yes, but not required.  The use above is to maintain output
formatting
> in a manner that is easy to parse - this isn''t an issue for input,
such as with chmod.
> Second, I think you need to make some logical assumptions about what the
input
> means.  For example, you have "attr:," to represent no
permissions for xattr.
> If there is no "attr:" then there are none applied (i.e. it has
the same impact as
> the empty "attr:").  So the above could also be:
> 
> chmod A+owner@::allow=file:rwa,sync,user:barney:allow=file:rwx,sync file
> 
> What I don''t like here is "sync,user:...". 
That''s not clear enough.
> Maybe we should be using + instead?
> 
> chmod A+owner@::allow=file:rwa,sync+user:barney:allow=file:rwx,sync file
> 
> Can we then go on to do "chmod A+user:foo..-user:barney:.." ?
> 
> i.e. add an acl for user:foo and remove one for user:barney?
> 
No you cannot add one ACE and delete another in a single chmod(2).  The 
utility is currently desgined for adding, replacing or deleting not a 
mixture at the same time.  Trying to add a mixture will just add more 
complication than is needed.  Chmod needs to be kept as simple as possible.
> Darren
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Jan 6, 2006, at 8:31 AM, Sam Falkner wrote:
> % /usr/bin/ls -lV foo
> -rw-r--r--   1 nobody4  root           0 Dec 19 15:29 foo
>      0:   owner@:---x--------:deny
>      1:   owner@:rwp--A-W---Co-:allow
>      2:   group@:-wpx----------:deny
>      3:   group@:r-------------:allow
>      4:everyone@:-wpx-A-W---Co-:deny
>      5:everyone@:r---a-R---c--s:allow
I don''t have a dog in this fight, but as a casual observer let me say  
that this is the most readable of any of the long-verbose listings  
I''ve seen.

--Jim

Sam Falkner <Sam.Falkner at Sun.COM> wrote:
> Here''s some example output from the proposed scheme.  "ls
-lv" is
> copied from a real ZFS file system, "ls -lV" is done by hand; any
> errors are mine.  I prepended spaces to the "who" entries for
owner@
Please try to hack the ls/acltext source and provide us with a way to test.

Things like that may only be rated if you are able to run it on  real data.

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:
> Sam Falkner <Sam.Falkner at Sun.COM> wrote:
> 
> 
>>Here''s some example output from the proposed scheme.  "ls
-lv" is
>>copied from a real ZFS file system, "ls -lV" is done by hand;
any
>>errors are mine.  I prepended spaces to the "who" entries for
owner@
> 
> 
> Please try to hack the ls/acltext source and provide us with a way to test.
> 
> Things like that may only be rated if you are able to run it on  real data.
> 
> J?rg
> 
Here is some sample output after modifying ls.

$ ls -V /sandbox
total 3
-rw-r--r--   1 root     root           0 Jan  6 10:46 a
             owner@:---x----------:------:deny
             owner@:rwp--W--A--Co-:------:allow
             group@:-wpx----------:------:deny
             group@:r-------------:------:allow
          everyone@:-wpx-W--A--Co-:------:deny
          everyone@:r---R--a--c--s:------:allow
drwxr-xr-x+  2 root     root           2 Jan  6 11:03 dir.1
            user:lp:r-----------o-:fd----:allow
           user:bin:r-------------:f-----:allow
             owner@:--------------:------:deny
             owner@:rwpx-W--A--Co-:------:allow
             group@:-wp-----------:------:deny
             group@:r--x----------:------:allow
          everyone@:-wp--W--A--Co-:------:deny
          everyone@:r--xR--a--c--s:------:allow

The permission field uses the following letters.  These are the same 
letters that AIX uses.
	r = read_data
	w = write_data
	p = append_data
	R = read_xattr
	W = write_xattr
	x = execute
	D = delete_child
	a = read_attributes
	A = write_attributes
	d = delete
	c = read_acl
	C = write_acl
	o = write_owner
	s = synchronize

The permissions field is followed by the inheritance field.
	f = file_inherit
	d = dir_inherit
	i = inherit_only
	n = no_propagate
	S = successful_access (currently not supported)
	F = Failed_access     (currently not supported)

	the S and F flags will be used when the audit/alarm access types
	are implemented.


    -Mark

From: "Mark Shellenbaum" <Mark.Shellenbaum at
Sun.COM>
>> Following on from the above theme:
>> file:rwaxd,named:rw,attr:rw,acl:rw,,chown,sync,
>> dir:rwad,named:rw,attr:rw,acl:rw,inherit:fdon,chown,sync,rm
>>
>
> This is starting to look a bit complicated.  You have permissions mixed in 
> with inheritance.  This is going to confuse more people than it helps. 
> Think about the novice user that has a hard time understanding the 
> difference between what file vs attr vs dir means.  Sure a seasoned 
> sysadmin will understand the difference, but what about a casual user.
They''re all stored in the same set of bits, so I don''t
necessarily see them
as being different.  It may help to reorder them, put inherit last or 
something
of that ilk, to aid in the understanding.  Moving inherit to being last 
would
eliminate the ",," from the middle.

file:rwaxd,named:rw,attr:rw,acl:rw,chown,sync,,
dir:rwad,named:rw,attr:rw,acl:rwx,chown,sync,rm,inherit:fdon

and pad out "dir" with a leading space.  Reformatting, we have:

allow user@:     file:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,,
 deny group:staff 
dir:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,rm,inherit:fdon

I''ve shuffled around allow/deny, putting it at the start like most
ACLs,
and have introduced more white spaces to seperate column types.

A potention problem is this is closing in on 80 characters with a real 
username
or group present, for directories with inherit bits set.
So perhaps "rm" becomes "D" next to "dir:" ?
Or is this game going to be lost eventually, so why bother trying to win 
that battle?

allow user@:     file:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,
 deny group:staff dir:rwadD,acl:rw,attr:rw,named:rw,chown,sync,inherit:fdon
> This is also going to fail the test of being able to quickly scan a 
> listing for a given permission.
I''m not sure that this is the goal of this output format - the
information
is still
too verbose to do that and requires some comprehension by the brain.  The
goal here is to provide meaningful output that isn''t too dense.

As Joerg noted, there''s perhaps room for two styles of extended output,
with
"ls -lv" and "ls -lV".

What I want, however, is to be able to do "ls -l . | egrep pattern"
and get
files with ACLs that have that permission bit set.  Or is that just pipe 
dreaming?

Do I need to do "find /zfs -acl allow/user:marks/acl:w,chown -print" ?

Darren

From: "Mark Shellenbaum" <Mark.Shellenbaum at
Sun.COM>
>> Following on from the above theme:
>> file:rwaxd,named:rw,attr:rw,acl:rw,,chown,sync,
>> dir:rwad,named:rw,attr:rw,acl:rw,inherit:fdon,chown,sync,rm
>>
>
> This is starting to look a bit complicated.  You have permissions mixed in 
> with inheritance.  This is going to confuse more people than it helps. 
> Think about the novice user that has a hard time understanding the 
> difference between what file vs attr vs dir means.  Sure a seasoned 
> sysadmin will understand the difference, but what about a casual user.
They''re all stored in the same set of bits, so I don''t
necessarily see them
as being different.  It may help to reorder them, put inherit last or 
something
of that ilk, to aid in the understanding.  Moving inherit to being last 
would
eliminate the ",," from the middle.

file:rwaxd,named:rw,attr:rw,acl:rw,chown,sync,,
dir:rwad,named:rw,attr:rw,acl:rwx,chown,sync,rm,inherit:fdon

and pad out "dir" with a leading space.  Reformatting, we have:

allow user@:     file:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,,
 deny group:staff 
dir:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,rm,inherit:fdon

I''ve shuffled around allow/deny, putting it at the start like most
ACLs,
and have introduced more white spaces to seperate column types.

A potention problem is this is closing in on 80 characters with a real 
username
or group present, for directories with inherit bits set.
So perhaps "rm" becomes "D" next to "dir:" ?
Or is this game going to be lost eventually, so why bother trying to win 
that battle?

allow user@:     file:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,
 deny group:staff dir:rwadD,acl:rw,attr:rw,named:rw,chown,sync,inherit:fdon
> This is also going to fail the test of being able to quickly scan a 
> listing for a given permission.
I''m not sure that this is the goal of this output format - the
information
is still
too verbose to do that and requires some comprehension by the brain.  The
goal here is to provide meaningful output that isn''t too dense.

As Joerg noted, there''s perhaps room for two styles of extended output,
with
"ls -lv" and "ls -lV".

What I want, however, is to be able to do "ls -l . | egrep pattern"
and get
files with ACLs that have that permission bit set.  Or is that just pipe 
dreaming?

Do I need to do "find /zfs -acl allow/user:marks/acl:w,chown -print" ?

Darren

From: "Mark Shellenbaum" <Mark.Shellenbaum at
Sun.COM>
>> Following on from the above theme:
>> file:rwaxd,named:rw,attr:rw,acl:rw,,chown,sync,
>> dir:rwad,named:rw,attr:rw,acl:rw,inherit:fdon,chown,sync,rm
>>
>
> This is starting to look a bit complicated.  You have permissions mixed in 
> with inheritance.  This is going to confuse more people than it helps. 
> Think about the novice user that has a hard time understanding the 
> difference between what file vs attr vs dir means.  Sure a seasoned 
> sysadmin will understand the difference, but what about a casual user.
They''re all stored in the same set of bits, so I don''t
necessarily see them
as being different.  It may help to reorder them, put inherit last or 
something
of that ilk, to aid in the understanding.  Moving inherit to being last 
would
eliminate the ",," from the middle.

file:rwaxd,named:rw,attr:rw,acl:rw,chown,sync,,
dir:rwad,named:rw,attr:rw,acl:rwx,chown,sync,rm,inherit:fdon

and pad out "dir" with a leading space.  Reformatting, we have:

allow user@:     file:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,,
 deny group:staff 
dir:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,rm,inherit:fdon

I''ve shuffled around allow/deny, putting it at the start like most
ACLs,
and have introduced more white spaces to seperate column types.

A potention problem is this is closing in on 80 characters with a real 
username
or group present, for directories with inherit bits set.
So perhaps "rm" becomes "D" next to "dir:" ?
Or is this game going to be lost eventually, so why bother trying to win 
that battle?

allow user@:     file:rwaxd,acl:rw,attr:rw,named:rw,chown,sync,
 deny group:staff dir:rwadD,acl:rw,attr:rw,named:rw,chown,sync,inherit:fdon
> This is also going to fail the test of being able to quickly scan a 
> listing for a given permission.
I''m not sure that this is the goal of this output format - the
information
is still
too verbose to do that and requires some comprehension by the brain.  The
goal here is to provide meaningful output that isn''t too dense.

As Joerg noted, there''s perhaps room for two styles of extended output,
with
"ls -lv" and "ls -lV".

What I want, however, is to be able to do "ls -l . | egrep pattern"
and get
files with ACLs that have that permission bit set.  Or is that just pipe 
dreaming?

Do I need to do "find /zfs -acl allow/user:marks/acl:w,chown -print" ?

Darren

Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:
> Joerg Schilling wrote:
> > Sam Falkner <Sam.Falkner at Sun.COM> wrote:
> > 
> > 
> >>Here''s some example output from the proposed scheme. 
"ls -lv" is
> >>copied from a real ZFS file system, "ls -lV" is done by
hand; any
> >>errors are mine.  I prepended spaces to the "who" entries
for owner@
> > 
> > 
> > Please try to hack the ls/acltext source and provide us with a way to
test.
> > 
> > Things like that may only be rated if you are able to run it on  real
data.
> > 
> > J?rg
> > 
>
> Here is some sample output after modifying ls.
>
> $ ls -V /sandbox
> total 3
> -rw-r--r--   1 root     root           0 Jan  6 10:46 a
>              owner@:---x----------:------:deny
>              owner@:rwp--W--A--Co-:------:allow
>              group@:-wpx----------:------:deny
>              group@:r-------------:------:allow
>           everyone@:-wpx-W--A--Co-:------:deny
>           everyone@:r---R--a--c--s:------:allow
> drwxr-xr-x+  2 root     root           2 Jan  6 11:03 dir.1
>             user:lp:r-----------o-:fd----:allow
>            user:bin:r-------------:f-----:allow
>              owner@:--------------:------:deny
>              owner@:rwpx-W--A--Co-:------:allow
>              group@:-wp-----------:------:deny
>              group@:r--x----------:------:allow
>           everyone@:-wp--W--A--Co-:------:deny
>           everyone@:r--xR--a--c--s:------:allow
>
> The permission field uses the following letters.  These are the same 
> letters that AIX uses.
> 	r = read_data
> 	w = write_data
> 	p = append_data
	^^^
	Something thart does not look nice
> 	R = read_xattr
> 	W = write_xattr
> 	x = execute
> 	D = delete_child
> 	a = read_attributes
> 	A = write_attributes
	a/A is also a bad choice.
	People would have problems to understand that
	a missing ''a'' means no stat(2)
	also ''A'' means the right to set the time....
> 	d = delete
> 	c = read_acl
> 	C = write_acl
	c/C is a bad choice for ACLs
> 	o = write_owner
> 	s = synchronize
>
> The permissions field is followed by the inheritance field.
> 	f = file_inherit
> 	d = dir_inherit
> 	i = inherit_only
> 	n = no_propagate
> 	S = successful_access (currently not supported)
> 	F = Failed_access     (currently not supported)
>
> 	the S and F flags will be used when the audit/alarm access types
> 	are implemented.
It is similar to my proposal but I don''t like this to become the final
way as I would like to see e.g. that the file permissoions are separated
from the meta data permissions.

Do you have the modified source?

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

>> The permission field uses the following letters.  These are the same 
>> letters that AIX uses.
>> 	r = read_data
>> 	w = write_data
>> 	p = append_data
>	^^^
>	Something thart does not look nice
"a" would be better.
>> 	R = read_xattr
>> 	W = write_xattr
>> 	x = execute
>> 	D = delete_child
>> 	a = read_attributes
>> 	A = write_attributes
>	a/A is also a bad choice.
>	People would have problems to understand that
>	a missing ''a'' means no stat(2)
>	also ''A'' means the right to set the time....
Traditionally, other operating systems I''ve used with "ACLs"
have used
the "O" (for owner) attribute to specify whether you were allowed to
act "as if" you are the owner of a file.

(I seem to remember "OWARE" from AOS/VS; (Owner, Write, Append, Read, 
Execute)

"X" for execute is fine, though.  But "A" for
"ACLs" is too confusing.


Casper

Sorry, I never got back to you on the documentation for AIX''s  
representation.  Unfortunately, I haven''t been able to deep-link to  
it, so here''s what to do.  If the 1st URL below doesn''t work,
it''s
intended to be a link to "Securing NFS in AIX An Introduction to NFS  
v4 in AIX 5L Version 5.3".

Go to http://www.redbooks.ibm.com/abstracts/SG247204.html?Open
Click on "view as html".
Click these book icons on the left: "Chapter 3...",
"3.4...",
"3.4.3...", "NFS V4 ACL format".

- Sam

On Jan 9, 2006, at 4:36 AM, Joerg Schilling wrote:
> Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:
>
>> Joerg Schilling wrote:
>>> Sam Falkner <Sam.Falkner at Sun.COM> wrote:
>>>
>>>
>>>> Here''s some example output from the proposed scheme. 
"ls -lv" is
>>>> copied from a real ZFS file system, "ls -lV" is done
by hand; any
>>>> errors are mine.  I prepended spaces to the "who"
entries for
>>>> owner@
>>>
>>>
>>> Please try to hack the ls/acltext source and provide us with a  
>>> way to test.
>>>
>>> Things like that may only be rated if you are able to run it on   
>>> real data.
>>>
>>> J?rg
>>>
>>
>> Here is some sample output after modifying ls.
>>
>> $ ls -V /sandbox
>> total 3
>> -rw-r--r--   1 root     root           0 Jan  6 10:46 a
>>              owner@:---x----------:------:deny
>>              owner@:rwp--W--A--Co-:------:allow
>>              group@:-wpx----------:------:deny
>>              group@:r-------------:------:allow
>>           everyone@:-wpx-W--A--Co-:------:deny
>>           everyone@:r---R--a--c--s:------:allow
>> drwxr-xr-x+  2 root     root           2 Jan  6 11:03 dir.1
>>             user:lp:r-----------o-:fd----:allow
>>            user:bin:r-------------:f-----:allow
>>              owner@:--------------:------:deny
>>              owner@:rwpx-W--A--Co-:------:allow
>>              group@:-wp-----------:------:deny
>>              group@:r--x----------:------:allow
>>           everyone@:-wp--W--A--Co-:------:deny
>>           everyone@:r--xR--a--c--s:------:allow
>>
>> The permission field uses the following letters.  These are the same
>> letters that AIX uses.
>> 	r = read_data
>> 	w = write_data
>> 	p = append_data
> 	^^^
> 	Something thart does not look nice
>
>> 	R = read_xattr
>> 	W = write_xattr
>> 	x = execute
>> 	D = delete_child
>> 	a = read_attributes
>> 	A = write_attributes
> 	a/A is also a bad choice.
> 	People would have problems to understand that
> 	a missing ''a'' means no stat(2)
> 	also ''A'' means the right to set the time....
>
>> 	d = delete
>> 	c = read_acl
>> 	C = write_acl
> 	c/C is a bad choice for ACLs
>
>> 	o = write_owner
>> 	s = synchronize
>>
>> The permissions field is followed by the inheritance field.
>> 	f = file_inherit
>> 	d = dir_inherit
>> 	i = inherit_only
>> 	n = no_propagate
>> 	S = successful_access (currently not supported)
>> 	F = Failed_access     (currently not supported)
>>
>> 	the S and F flags will be used when the audit/alarm access types
>> 	are implemented.
>
> It is similar to my proposal but I don''t like this to become the
final
> way as I would like to see e.g. that the file permissoions are  
> separated
> from the meta data permissions.
>
> Do you have the modified source?
>
> 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
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

> (I seem to remember "OWARE" from AOS/VS; (Owner, Write, Append,
Read, Execute)
Prime PRIMOS had ACLs also... A long time ago :-)

ALL rights = PDALURWX (ain''t it funny how certains lines of gibberish
get stuck? :-)

P = Protection (able to change rights)
D = Delete object
A = Access 
L = List directory
U = Use (approx "cd" to this dir)
R = Read
W = Write
X = Execute

What has this got to do with the current discussion? Not much :-): I too would
like to see some kind of abbreviated listing though... getfacl was too cryptic,
but the current verbosity madness is too much...
This message posted from opensolaris.org

Sam Falkner <Sam.Falkner at Sun.COM> wrote:
> Sorry, I never got back to you on the documentation for AIX''s  
> representation.  Unfortunately, I haven''t been able to deep-link
to
> it, so here''s what to do.  If the 1st URL below doesn''t
work, it''s
> intended to be a link to "Securing NFS in AIX An Introduction to NFS  
> v4 in AIX 5L Version 5.3".
>
> Go to http://www.redbooks.ibm.com/abstracts/SG247204.html?Open
> Click on "view as html".
> Click these book icons on the left: "Chapter 3...",
"3.4...",
> "3.4.3...", "NFS V4 ACL format".
Thank you! this works. I''ll have a deeper look at it later.
Yesterday I have been in Prague at the OpenSolaris usergroup meeting.

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

I would like to try and get some closure on this issue.

At this point I believe we have agreed to the following:

1. ls -v (remains unchanged for users who want verbose output)

2. A new option -V will be added to provide a more compact ACL output.

    The output of this option is the primary issue to be resolved.

    Since IBM has set a precedent for distinct letters to be used for
    describing the various permissions for NFSv4 ACLs. I would like to
    follow their lead so as to try and get some conformity in the
    industry for NFSv4 ACLs.

    I realize that not everyone will like all of the letter choices that
    IBM has chosen, but unfortunately no matter what letters you choose
    there will always be several letters that seem a bit out of place.

    By choosing distinct letters for the permissions the chmod utility
    can then be modified to allow for users to set ACLs in either a
    verbose syntax or the new compact single letter based style.

    For example:

         chmod A+user:marks:read_data/write_data/write_owner:allow
         or
         chmod A+user:marks:rxo:allow

    Previously we had proposed the following format:

$ ls -V /sandbox
total 3
-rw-r--r--   1 root     root           0 Jan  6 10:46 a
             owner@:--x-----------:------:deny
             owner@:rw-p-W--A--Co-:------:allow
             group@:-wxp----------:------:deny
             group@:r-------------:------:allow
          everyone@:-wxp-W--A--Co-:------:deny
          everyone@:r---R--a--c--s:------:allow

We can leave this as is or rearrange it to separate the meta data 
permissions.

-rw-r--r--   1 root     root           0 Jan  6 10:46 a
             owner@:--x---  --------:------:deny
             owner@:rw-p--  -A-W-Co-:------:allow
             group@:-wxp--  --------:------:deny
             group@:r-----  --------:------:allow
          everyone@:-wxp--  -A-W-Co-:------:deny
          everyone@:r-----  a---c--s:------:allow

         The first field has read_data,write_data, execute, append,
         delete and delete_child.

         The second field has read_attributes, write_attributes,
         read_xattr, write_xattr, read_acl, write_acl, write_owner
         and synchronize.

re: ls -V

While I still like the visual clarity of having two characters (See my posting
above, the char pairs would consist of an upper-case letter and a lower-case
character) for the "higher-end" ACL''s (I assume these are the
metadata you refer to?), I can understand the benefit of keeping some
consistency between various OSes.

Would it be possible to see what this looks like when listing a directory with
some 5 entries? I''m just worried about the readability as a directory
fills up with files.

Rainer
PS Please note that I''ve not had to deal with these extended
ACL''s before, nor do I have a spare system to try this on, so
I''m a little in the dark here. My apologies. I''m just trying
to give some feedback (and gain understanding) as a sysadmin that will have to
work with this over the long haul.
This message posted from opensolaris.org

Rainer Heilke wrote:
> re: ls -V
> 
> While I still like the visual clarity of having two characters (See my
posting above, the char pairs would consist of an upper-case letter and a
lower-case character) for the "higher-end" ACL''s (I assume
these are the metadata you refer to?), I can understand the benefit of keeping
some consistency between various OSes.
> 
I don''t like having a mixture of single letter and double letters 
permissions.  I think in the long run it will just add confusion, 
particularly when used in chmod for setting ACLs.  Users will need to 
understand that read attributes needs two letters, but read_data only 
needs an "r''.

Another problem with two letter abbreviations is that is breaks down for 
things such as read attributes and read acl.  You would be in a 
situation where you want Ra (Read attributes), but also want Ra (Read ACL).
> Would it be possible to see what this looks like when listing a directory
with some 5 entries? I''m just worried about the readability as a
directory fills up with files.
> 
I previously had posted an example with two entries. This isn''t with
the
meta data permissions separated out, but it would look pretty much the same.


$ ls -V /sandbox
total 3
-rw-r--r--   1 root     root           0 Jan  6 10:46 a
              owner@:---x----------:------:deny
              owner@:rwp--W--A--Co-:------:allow
              group@:-wpx----------:------:deny
              group@:r-------------:------:allow
           everyone@:-wpx-W--A--Co-:------:deny
           everyone@:r---R--a--c--s:------:allow
drwxr-xr-x+  2 root     root           2 Jan  6 11:03 dir.1
             user:lp:r-----------o-:fd----:allow
            user:bin:r-------------:f-----:allow
              owner@:--------------:------:deny
              owner@:rwpx-W--A--Co-:------:allow
              group@:-wp-----------:------:deny
              group@:r--x----------:------:allow
           everyone@:-wp--W--A--Co-:------:deny
           everyone@:r--xR--a--c--s:------:allow

With this you can quickly scan for certain permissions.

Thanks for the quick response.
> I don''t like having a mixture of single letter and
> double letters 
> permissions.  I think in the long run it will just
> add confusion, 
> particularly when used in chmod for setting ACLs.
>  Users will need to 
> understand that read attributes needs two letters,
> but read_data only 
> needs an "r''.
I can see the logic in that... I had only hoped for the visual differentiation,
rather than one long stream of single characters (please see additional comments
below).
> Another problem with two letter abbreviations is that
> is breaks down for 
> things such as read attributes and read acl.  You
> would be in a 
> situation where you want Ra (Read attributes), but
> also want Ra (Read ACL).
Yes, there would have to be some thumb-wrestling here, but not really any more
than there is under a single-letter scheme.
> I previously had posted an example with two entries.
> This isn''t with the 
> meta data permissions separated out, but it would
> look pretty much the same.
This whole thread has gotten a little convoluted, so my apologies for not seeing
your earlier example. :-)
> $ ls -V /sandbox
> total 3
> -rw-r--r--   1 root     root           0 Jan  6 10:46
> a
>               owner@:---x----------:------:deny
>               owner@:rwp--W--A--Co-:------:allow
>               group@:-wpx----------:------:deny
>               group@:r-------------:------:allow
>            everyone@:-wpx-W--A--Co-:------:deny
>            everyone@:r---R--a--c--s:------:allow
> drwxr-xr-x+  2 root     root           2 Jan  6 11:03
> dir.1
>              user:lp:r-----------o-:fd----:allow
>             user:bin:r-------------:f-----:allow
>               owner@:--------------:------:deny
>               owner@:rwpx-W--A--Co-:------:allow
>               group@:-wp-----------:------:deny
>               group@:r--x----------:------:allow
>            everyone@:-wp--W--A--Co-:------:deny
>            everyone@:r--xR--a--c--s:------:allow
> 
> With this you can quickly scan for certain
> permissions.
Hmm. OK, that''s clearer. It helps that, quoted like this, Internet
Exploder is now showing the spaces before the ACL lines...

So, now I''m going to make the next dumb point: there has been mention
of "first field" and "second field". I actually see four:
 owner:perms:something:deny/allow

Note that the colon in each line indicates a break to me, separating fields. I
can now see that you are using a space to actually separate the metadata
permissions (the first and second field). I would argue that when scanning fifty
files in a directory, the space will become invisible (as it was for me on the
first three readings of this). Using a fixed-width font, this may be less of an
issue, but for a proportional font (and I know many that use one in their
terminal sessions) this negates the usefulness. I''m therefore not sure
that the space has any value, and would probably leave it at your first example.
Or, perhaps a pipe (|) or some other symbol would be more visual?

I''m also left wondering what the third field (based on colons) is meant
for.

Thanks again.
Rainer
This message posted from opensolaris.org

Rainer Heilke wrote:
> Thanks for the quick response.
> 
> 
>>I don''t like having a mixture of single letter and
>>double letters 
>>permissions.  I think in the long run it will just
>>add confusion, 
>>particularly when used in chmod for setting ACLs.
>> Users will need to 
>>understand that read attributes needs two letters,
>>but read_data only 
>>needs an "r''.
> 
> 
> I can see the logic in that... I had only hoped for the visual
differentiation, rather than one long stream of single characters (please see
additional comments below).
> 
> 
>>Another problem with two letter abbreviations is that
>>is breaks down for 
>>things such as read attributes and read acl.  You
>>would be in a 
>>situation where you want Ra (Read attributes), but
>>also want Ra (Read ACL).
> 
> 
> Yes, there would have to be some thumb-wrestling here, but not really any
more than there is under a single-letter scheme.
> 
> 
>>I previously had posted an example with two entries.
>>This isn''t with the 
>>meta data permissions separated out, but it would
>>look pretty much the same.
> 
> 
> This whole thread has gotten a little convoluted, so my apologies for not
seeing your earlier example. :-)
> 
> 
>>$ ls -V /sandbox
>>total 3
>>-rw-r--r--   1 root     root           0 Jan  6 10:46
>>a
>>              owner@:---x----------:------:deny
>>              owner@:rwp--W--A--Co-:------:allow
>>              group@:-wpx----------:------:deny
>>              group@:r-------------:------:allow
>>           everyone@:-wpx-W--A--Co-:------:deny
>>           everyone@:r---R--a--c--s:------:allow
>>drwxr-xr-x+  2 root     root           2 Jan  6 11:03
>>dir.1
>>             user:lp:r-----------o-:fd----:allow
>>            user:bin:r-------------:f-----:allow
>>              owner@:--------------:------:deny
>>              owner@:rwpx-W--A--Co-:------:allow
>>              group@:-wp-----------:------:deny
>>              group@:r--x----------:------:allow
>>           everyone@:-wp--W--A--Co-:------:deny
>>           everyone@:r--xR--a--c--s:------:allow
>>
>>With this you can quickly scan for certain
>>permissions.
> 
> 
> Hmm. OK, that''s clearer. It helps that, quoted like this, Internet
Exploder is now showing the spaces before the ACL lines...
> 
> So, now I''m going to make the next dumb point: there has been
mention of "first field" and "second field". I actually see
four:
>  owner:perms:something:deny/allow
> 
The first field and second field applied to the grouping of permission 
bits in my second example from my earlier post.

The "something" is inheritance flags.
> Note that the colon in each line indicates a break to me, separating
fields. I can now see that you are using a space to actually separate the
metadata permissions (the first and second field). I would argue that when
scanning fifty files in a directory, the space will become invisible (as it was
for me on the first three readings of this). Using a fixed-width font, this may
be less of an issue, but for a proportional font (and I know many that use one
in their terminal sessions) this negates the usefulness. I''m therefore
not sure that the space has any value, and would probably leave it at your first
example. Or, perhaps a pipe (|) or some other symbol would be more visual?
> 
> I''m also left wondering what the third field (based on colons) is
meant for.
The third field is the inheritance flags.

f = file inherit
d = directory inherit
i = inherit only
n = no propagate

We also have place holder spaces for two additional inheritance flags 
which are not currently implemented.
> 
> Thanks again.
> Rainer
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

> The first field and second field applied to the
> grouping of permission 
> bits in my second example from my earlier post.
Right, I think I got that (as in my later comment that was below). :-)
> The "something" is inheritance flags.
> The third field is the inheritance flags.
> 
> f = file inherit
> d = directory inherit
> i = inherit only
> n = no propagate
> 
> We also have place holder spaces for two additional
> inheritance flags 
> which are not currently implemented.
OK, got it. Makes more sense to me now.

So, I''m not sure there''s any benefit to the one example over
the other. I think, visually speaking, empty spaces get lost in the sea, and
wouldn''t use them as separation characters. That''s just me.

Thanks again for the quick response. 

Rainer
This message posted from opensolaris.org

On 07/01/2006, at 2:15 AM, James C Thompson wrote:
> I don''t have a dog in this fight, but as a casual observer let me
> say that this is the most readable of any of the long-verbose  
> listings I''ve seen.
I admit that I haven''t been following this thread, and I don''t
have a
suggestion either, but I thought I''d mention something that came to  
me last night while I lay staring at the ceiling.

If seems to me that one of the things that makes the traditional ls - 
l / chmod syntax comparatively easy to use is that they provide the  
illusion of direct manipulation.

For example, if I see r--r--r-- and I want to add the write bit to  
the owner it feels like I''m directly manipulating the representation  
when I say u+w. I don''t have to do any translation from w ->  
"write_data" or whatever

If the output format and the setting format don''t look the same then  
I think we would lose this characteristic and the mnemonic qualities  
that it brings to the task.

Just my 2 cents.

Boyd