setfacl(2.4.0.15): for next year !!!!!

setfacl(2.4.0.15): for next year !!!!!

[Houder]

Hi Corinna,

For next year !!!!! (posted as a reminder) ... See below.

Regards,
Henri

64-%% uname -a
CYGWIN_NT-6.1 Seven 2.4.0(0.292/5/3) 2015-12-21 13:10 x86_64 Cygwin

64-%% touch bar.txt
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
other:r--

64-%% setfacl -m g:None:rw- -x g:None: bar.txt # add and delete ...
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
group:None:rwx <==== surprise! (this one, I did not even specify!)
mask:rwx
other:r--

64-%% ls -l bar.txt
-rw-rwxr--+ 1 Henri None 0 Dec 21 17:06 bar.txt
64-%% setfacl -x m: bar.txt
setfacl: Invalid argument <==== nice ... as there is still a g:uid:perm 
entry

64-%% setfacl -x g:None:,m: bar.txt
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
other:r--

64-%% # Hurrah!

-----
in stead of the last 'setfacl' command above:

64-%% setfacl -x g:None: bar.txt
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
mask:r-- <==== uhm, superfluous ...
other:r--

64-%% setfacl -x m: bar.txt
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
other:r--

64-%% # Hurrah!

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setfacl(2.4.0.15): for next year !!!!!

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On Dec 21 17:30, Houder wrote:
> Hi Corinna,
> 
> For next year !!!!! (posted as a reminder) ... See below.

Next year?  Nope... see below.

> Regards,
> Henri
> 
> 64-%% uname -a
> CYGWIN_NT-6.1 Seven 2.4.0(0.292/5/3) 2015-12-21 13:10 x86_64 Cygwin
> 
> 64-%% touch bar.txt
> 64-%% getfacl bar.txt
> # file: bar.txt
> # owner: Henri
> # group: None
> user::rw-
> group::r--
> other:r--
> 
> 64-%% setfacl -m g:None:rw- -x g:None: bar.txt # add and delete ...
> 64-%% getfacl bar.txt
> # file: bar.txt
> # owner: Henri
> # group: None
> user::rw-
> group::r--
> group:None:rwx <==== surprise! (this one, I did not even specify!)
> mask:rwx
> other:r--

Heh.  I added a mode to allow modify and delete in a single command but
didn't actually handle it in the code.  I'm sure I tested it at one
point... or... at least... planned to test it... uhm...

> in stead of the last 'setfacl' command above:
> 
> 64-%% setfacl -x g:None: bar.txt
> 64-%% getfacl bar.txt
> # file: bar.txt
> # owner: Henri
> # group: None
> user::rw-
> group::r--
> mask:r-- <==== uhm, superfluous ...

But the same behaviour as with Linux setfacl.  You did *not* request to
delete the mask, after all.

Just uploaded a 0.16 test release to fix the -m/-x...


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: setfacl(2.4.0.15): for next year !!!!!

[Houder]

On 2015-12-21 18:25, Corinna Vinschen wrote:
> On Dec 21 17:30, Houder wrote:
>> Hi Corinna,
>> 
>> For next year !!!!! (posted as a reminder) ... See below.
> 
> Next year?  Nope... see below.
> 

Hi Corinna,

Thank you for all the hard work you do ...

As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16). 
<==== 16

Regards,
Henri

-----
64-%% uname -a
CYGWIN_NT-6.1 Seven 2.4.0(0.292/5/3) 2015-12-21 18:20 x86_64 Cygwin
64-%% touch bar.txt
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
other:r--

64-%% setfacl -m m:rwx bar.txt
64-%% getfacl bar.txt
# file: bar.txt
# owner: Henri
# group: None
user::rw-
group::r--
mask:rwx <==== yes, as requested by me, but ...
other:r--

64-%% ls -l bar.txt
-rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt

  - does this output make sense?
    (no access to Linux at the moment; cannot verify)

64-%%

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setfacl(2.4.0.15): for next year !!!!! continued

[Houder]

On 2015-12-22 12:37, Houder wrote:
> On 2015-12-21 18:25, Corinna Vinschen wrote:
>> On Dec 21 17:30, Houder wrote:
>>> Hi Corinna,
>>> 
>>> For next year !!!!! (posted as a reminder) ... See below.
>> 
>> Next year?  Nope... see below.
>> 
> 
> Hi Corinna,
> 
> Thank you for all the hard work you do ...
> 
> As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16). 
> <==== 16
[snip]
> 64-%% setfacl -m m:rwx bar.txt
> 64-%% getfacl bar.txt
> # file: bar.txt
> # owner: Henri
> # group: None
> user::rw-
> group::r--
> mask:rwx <==== yes, as requested by me, but ...
> other:r--
> 
> 64-%% ls -l bar.txt
> -rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt
> 
>  - does this output make sense?
>    (no access to Linux at the moment; cannot verify)

 From acl(5):

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS

      The permissions defined by ACLs are a superset of the permissions
      specified by the file permission bits.

      There is a correspondence between the file owner, group, and other
      permissions and specific ACL entries: the owner permissions 
correspond
      to the permissions of the ACL_USER_OBJ entry. If the ACL has an 
<==== yes, but ...
      ACL_MASK entry, the group permissions correspond to the permissions 
of
      the ACL_MASK entry.

 From setfacl(1);

OPTIONS

-n, --no-mask
            Do not recalculate the effective rights mask. The default
            behavior of setfacl is to recalculate the ACL mask entry, 
unless
            a mask entry was explicitly given.  The mask entry is set to 
the <==== Oh, ah!
            union of all permissions of the owning group, and all named 
user
            and group entries. (These are exactly the entries affected by 
the
            mask entry).


setfacl.c:

int
recompute_mask (aclent_t *tgt, int tcnt, int got_mask, int got_def_mask)
{
...
  /* Recompute mask, if requested
      - If we got a mask in the input string, recompute only if --mask 
has been
        specified.
...
Your call, Corinna ... but reading setfacl(1)

Regards,

Henri

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setfacl(2.4.0.15): for next year !!!!! continued (2)

[Houder]

On 2015-12-22 12:37, Houder wrote:
> On 2015-12-21 18:25, Corinna Vinschen wrote:
>> On Dec 21 17:30, Houder wrote:
>>> Hi Corinna,
>>> 
>>> For next year !!!!! (posted as a reminder) ... See below.
>> 
>> Next year?  Nope... see below.
>> 
> 
> Hi Corinna,
> 
> Thank you for all the hard work you do ...
> 
> As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16). 
> <==== 16
[snip]

> 64-%% setfacl -m m:rwx bar.txt
> 64-%% getfacl bar.txt
> # file: bar.txt
> # owner: Henri
> # group: None
> user::rw-
> group::r--
> mask:rwx <==== yes, as requested by me, but ...
> other:r--
> 
> 64-%% ls -l bar.txt
> -rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt
> 
>  - does this output make sense?
>    (no access to Linux at the moment; cannot verify)

To make it clear what I meant by 'but reading setfacl(1)' (previous 
post):

 From setfacl(1):

OPTIONS

  -n ...

(description)
The default behavior of setfacl is to recalculate the ACL mask entry, 
unless
a mask entry was explicitly given.

(my interpretation)
  - unless a mask entry with "less privileges" was specified (i.e. given) 
...
    (i.e. the mask must still be (internally) recalculated , using the 
rules as
     stated further down)

What I mean to say, is:
  - the mask entry should be the calculated mask, unless the specified 
(i.e. given)
    mask takes away one or more of the privileges of the calculated mask.
    if so, the mask entry should be the calculated mask, save for the 
privileges
    that have been taken away ...

(description continued)
The mask entry is set to the union of all permissions of the owning 
group, and
all named user and group entries.
(These are exactly the entries affected by the mask entry).

Regards,
Henri

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setfacl(2.4.0.15): for next year !!!!!

[Houder]

On 2015-12-22 12:37, Houder wrote:
> On 2015-12-21 18:25, Corinna Vinschen wrote:
>> On Dec 21 17:30, Houder wrote:
>>> Hi Corinna,
>>> 
>>> For next year !!!!! (posted as a reminder) ... See below.
>> 
>> Next year?  Nope... see below.
>> 
> 
> Hi Corinna,
> 
> Thank you for all the hard work you do ...
> 
> As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16). 
> <==== 16
[snip]

> 64-%% setfacl -m m:rwx bar.txt
> 64-%% getfacl bar.txt
> # file: bar.txt
> # owner: Henri
> # group: None
> user::rw-
> group::r--
> mask:rwx <==== yes, as requested by me, but ...
> other:r--
> 
> 64-%% ls -l bar.txt
> -rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt
> 
>  - does this output make sense?
>    (no access to Linux at the moment; cannot verify)

Just got myself access to Linux (FC19) ... old, yes.

FC19 has the same "weird" (to me) behaviour as Cygwin now has. The
difference is that 'ls -l' on FC19 shows an additional plus sign.

As follows:

-rw-rwxr--+ 1 Henri ... bar.txt

So, the definition of the mask entry is slightly different than I
argued in my post before this one -- ... continued (2) --.

Regards,
Henri

======

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setfacl(2.4.0.15): for next year !!!!!

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

On Dec 22 15:42, Houder wrote:
> On 2015-12-22 12:37, Houder wrote:
> >On 2015-12-21 18:25, Corinna Vinschen wrote:
> >>On Dec 21 17:30, Houder wrote:
> >>>Hi Corinna,
> >>>
> >>>For next year !!!!! (posted as a reminder) ... See below.
> >>
> >>Next year?  Nope... see below.
> >>
> >
> >Hi Corinna,
> >
> >Thank you for all the hard work you do ...
> >
> >As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16).
> ><==== 16
> [snip]
> 
> >64-%% setfacl -m m:rwx bar.txt
> >64-%% getfacl bar.txt
> ># file: bar.txt
> ># owner: Henri
> ># group: None
> >user::rw-
> >group::r--
> >mask:rwx <==== yes, as requested by me, but ...
> >other:r--
> >
> >64-%% ls -l bar.txt
> >-rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt
> >
> > - does this output make sense?
> >   (no access to Linux at the moment; cannot verify)
> 
> Just got myself access to Linux (FC19) ... old, yes.
> 
> FC19 has the same "weird" (to me) behaviour as Cygwin now has.

It's correct.  The rule is that the group perms reflect the mask
if a mask is present, the primary group perms otherwise.

> The
> difference is that 'ls -l' on FC19 shows an additional plus sign.

This is a problem in ls itself.  The reason is that with the start of
reimplementing the ACL handling (back in August 2014), the definition of
MIN_ACL_ENTRIES changed from 4 to 3.

I recall having a discussion with eblake (coreutils maintainer) via IRC
in 2014 where we discussed this.  At that time the mask entry was only
fasked, so we came up with the fact that there's never an aclent_t with
4 entries, so ls is still using the old definition to maintain backward
compat.

With the new code in 2.4.0 it's probably time to drop this Cygwin-specific
workaround in coreutils (but it doesn't hurt much either).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: setfacl(2.4.0.15): for next year !!!!!

[Houder]

On 2015-12-23 11:50, Corinna Vinschen wrote:
> On Dec 22 15:42, Houder wrote:
>> On 2015-12-22 12:37, Houder wrote:
>> >On 2015-12-21 18:25, Corinna Vinschen wrote:
>> >>On Dec 21 17:30, Houder wrote:
>> >>>Hi Corinna,
>> >>>
>> >>>For next year !!!!! (posted as a reminder) ... See below.
>> >>
>> >>Next year?  Nope... see below.
>> >>
>> >
>> >Hi Corinna,
>> >
>> >Thank you for all the hard work you do ...
>> >
>> >As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16).
>> ><==== 16
>> [snip]
>> 
>> >64-%% setfacl -m m:rwx bar.txt
>> >64-%% getfacl bar.txt
>> ># file: bar.txt
>> ># owner: Henri
>> ># group: None
>> >user::rw-
>> >group::r--
>> >mask:rwx <==== yes, as requested by me, but ...
>> >other:r--
>> >
>> >64-%% ls -l bar.txt
>> >-rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt
>> >
>> > - does this output make sense?
>> >   (no access to Linux at the moment; cannot verify)
>> 
>> Just got myself access to Linux (FC19) ... old, yes.
>> 
>> FC19 has the same "weird" (to me) behaviour as Cygwin now has.
> 
> It's correct.  The rule is that the group perms reflect the mask
> if a mask is present, the primary group perms otherwise.

Agreed. That is what acl(5) asserts ...
( CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS )

It also asserts that 'ls -l' should show the plus sign here ...
( CHANGES TO THE FILE UTILITIES )

>> The
>> difference is that 'ls -l' on FC19 shows an additional plus sign.
> 
> This is a problem in ls itself.  The reason is that with the start of
> reimplementing the ACL handling (back in August 2014), the definition 
> of
> MIN_ACL_ENTRIES changed from 4 to 3.
> 
> I recall having a discussion with eblake (coreutils maintainer) via IRC
> in 2014 where we discussed this.  At that time the mask entry was only
> fasked, so we came up with the fact that there's never an aclent_t with
> 4 entries, so ls is still using the old definition to maintain backward
> compat.
> 
> With the new code in 2.4.0 it's probably time to drop this 
> Cygwin-specific
> workaround in coreutils (but it doesn't hurt much either).

Does't hurt?

Well, without the plus sign, the output of 'ls -l' looks 
suspicious/weird to
me in case of the example above ...

Perhaps Eric agrees ...

Regards,
Henri

> 
> Corinna

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setfacl(2.4.0.15): for next year !!!!!

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Dec 23 12:10, Houder wrote:
> On 2015-12-23 11:50, Corinna Vinschen wrote:
> >On Dec 22 15:42, Houder wrote:
> >>The
> >>difference is that 'ls -l' on FC19 shows an additional plus sign.
> >
> >This is a problem in ls itself.  The reason is that with the start of
> >reimplementing the ACL handling (back in August 2014), the definition of
> >MIN_ACL_ENTRIES changed from 4 to 3.
> >
> >I recall having a discussion with eblake (coreutils maintainer) via IRC
> >in 2014 where we discussed this.  At that time the mask entry was only
> >fasked, so we came up with the fact that there's never an aclent_t with
> >4 entries, so ls is still using the old definition to maintain backward
> >compat.
> >
> >With the new code in 2.4.0 it's probably time to drop this Cygwin-specific
> >workaround in coreutils (but it doesn't hurt much either).
> 
> Does't hurt?
> 
> Well, without the plus sign, the output of 'ls -l' looks suspicious/weird to
> me in case of the example above ...

Now that you mention it... I agree.  It might hurt.  But it's a rather
seldom border case, so the confusion should be rather limited :)

> Perhaps Eric agrees ...

Yes, he very likely agrees.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]