Issues with ACL settings after updating to the latest cygwin.dll - correction

Issues with ACL settings after updating to the latest cygwin.dll - correction

[akikij]

Hi,
I have the different problems you have about this new security right NULL SID DENY added to some files.
Sometimes also Windows can't access files concerned.
He considered security rigths unordered and I have to class them before continue.
It's too difficult for me to help you to correct the problem.
I give only tracks to correct the effects to return to a clean situation.

I have a solution to list all files concerned in a directory tree:
#!/bin/bash
#	List on stdout objects with DENY
if [ $# -eq 0 ] ; then echo "Usage $0 path" ; exit 1 ; fi
cd "$1" || { echo "Bad path" ; exit 1; }
find . |grep -v -E '^\.$|RECYCLE.BIN|RECYCLER|System Volume Information'|while read i 
do	#echo "$i"
	1>&2 echo -en "$i\\r" #to see progression
	j=$(cygpath "$i")
	c=$(2>/dev/null cacls "$j" /L)
	if [ $? -ne 0 ] ; then
		s=$(file "$i"|grep 'symbolic link to')
		if [ -z "$s" ] ; then echo "not found $j" ; fi
		continue
	fi
	s=$(echo "$c"|grep -i 'NULL SID:(DENY)')
	if [ ! -z "$s" ] ; then
		echo "$c" 
	fi 
done |tee /tmp/1

I use here /tmp/1 as buffer. I can edit it before to submit to the next solution.
It's more safe for the moment.

I have another solution to patch security items contained in this buffer (here /tmp/1)
#!/bin/bash
#	Patch objects recognized having NULL SID right
#	one to one - with icacls - exit at the 1st error
ws=/tmp/NULSID	#root name for 2 temporary files, .org .new as suffixe
cat /tmp/1|grep '^.:'|while read -r i ; do
	j=$(echo "$i"|sed 's/ NULL SID.*//')
	echo "	chg $j"
	corg="$ws.org"
	cnew="$ws.new"
	icacls "$j" /save $(cygpath -w "$corg") || exit 1
	#edit with null char temporary remplaced
	cat "$corg"|tr '\0' '£'|sed -e '1 s/.*/.£/' -e 's/(£D[^)]*)£//g'|tr '£' '\0' > "$cnew"
	icacls "$j" /restore $(cygpath -w "$cnew") || exit 1
done

This solution not complete is usable for me now. I find many pbs in cygwin system
 (more than 3000 in /bin /lib ...)
I am not confident to leave this problem with ACLs. Some files are concerned, the others not.
I want a more deterministic function for the cygwin system.
May be an upgrade of all project datas is necessary before the use of these new acl functionnalities.

Sorry for my english

Regards


--
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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

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

Hi Akiki(?),

On Mar  4 16:43, akikij@free.fr wrote:
> Hi,
> I have the different problems you have about this new security right NULL SID DENY added to some files.

I still doubt the NULL ACE is the actual culprit of whatever you
observe.  A NULL ACE doesn't affect your permissions, unless you have a
NULL SID in your user token, which is extremly unlikely.

> Sometimes also Windows can't access files concerned.
> He considered security rigths unordered and I have to class them before continue.
> It's too difficult for me to help you to correct the problem.

No, I don't think so.

First of all, the order in the ACL is deliberate to provide an emulation
of POSIX permissions.  Don't reorder the ACL using Windows means, this
*will* break the ACL evaluation.

Please also note that the Windows OS does *not* fail to evaluate an
ACL just because it's not in the so-called "canonical order".  The
OS strictly evaluates the ACL top-down, from the first to the last ACE,
without worrying about the order.  Only the GUI and certain Windows
tools written to manipulate an ACL (e.g. icacls) will choke on such ACLs.
Don't use such tools on Cygwin-created ACLs.  Use Cygwin's chmod, chown,
and setfacl for this.

My problem is this: You're the third person on this list reporting a
problem along the lines of "ACL doesn't work with Windows", without
giving me a clear reproducer.

What I need is a clear description what *exactly* you do and what
*exactly* fails.  I assume you created a file using some Cygwin tool
and then try to access it from non-Cygwin tools.  Are you unable to
read or write the file using that Windows tool?  Are you expecting
to double click on the file to execute something?  I really need a 
simple description which is easily reproduced using Windows system
tools.

What I then also need is that you do *NOT* try to *fix* the ACL, but
rather send me

- icacls output of the file and its parent dir
- getfacl output of the file and its parent dir

*If* there's a real problem, I need to be able to reproduce it,
otherwise I won't be able to fix it in Cygwin.


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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[akikij]

Hi, Corinna

To be clear about my problems about ACL.
A very simple example to observe.

I go to the root disk (C:\ or /cygdrive/c upon the system)
I can't create a file here (normally protected).
So I use administrator rights to do that with cmd and bash.

In cmd :
C:\>echo > xx
C:\>cacls xx
C:\xx BUILTIN\Administrateurs:(ID)F
      AUTORITE NT\Système:(ID)F
      BUILTIN\Utilisateurs:(ID)R
      AUTORITE NT\Utilisateurs authentifiés:(ID)C

Sorry I am french, but I say Ok why not.

In bash :
user@HOST /cygdrive/c -- my prompt bash not repeated after
$ echo > x
$ cacls x
C:\x NULL SID:(DENY)(accès spécial :)
              READ_CONTROL
              FILE_WRITE_EA
              FILE_EXECUTE
              FILE_DELETE_CHILD

     ASUS38\andre:(accès spécial :)
                  STANDARD_RIGHTS_ALL
                  DELETE
                  READ_CONTROL
                  WRITE_DAC
                  WRITE_OWNER
                  SYNCHRONIZE
                  STANDARD_RIGHTS_REQUIRED
                  FILE_GENERIC_READ
                  FILE_GENERIC_WRITE
                  FILE_READ_DATA
                  FILE_WRITE_DATA
                  FILE_APPEND_DATA
                  FILE_READ_EA
                  FILE_WRITE_EA
                  FILE_READ_ATTRIBUTES
                  FILE_WRITE_ATTRIBUTES

     BUILTIN\Administrateurs:(DENY)(accès spécial :)
                             FILE_EXECUTE

     AUTORITE NT\Utilisateurs authentifiés:(DENY)(accès spécial 
                                           FILE_EXECUTE

     AUTORITE NT\Système:(DENY)(accès spécial :)
                         FILE_EXECUTE

     BUILTIN\Utilisateurs:(DENY)(accès spécial :)
                          FILE_EXECUTE

     ASUS38\Aucun:(accès spécial :)
                  READ_CONTROL
                  SYNCHRONIZE
                  FILE_GENERIC_READ
                  FILE_READ_DATA
                  FILE_READ_EA
                  FILE_READ_ATTRIBUTES

     BUILTIN\Administrateurs:(accès spécial :)
                             READ_CONTROL
                             SYNCHRONIZE
                             FILE_GENERIC_READ
                             FILE_GENERIC_WRITE
                             FILE_GENERIC_EXECUTE
                             FILE_READ_DATA
                             FILE_WRITE_DATA
                             FILE_APPEND_DATA
                             FILE_READ_EA
                             FILE_WRITE_EA
                             FILE_EXECUTE
                             FILE_READ_ATTRIBUTES
                             FILE_WRITE_ATTRIBUTES

     AUTORITE NT\Utilisateurs authentifiés:(accès spécial :)
                                           READ_CONTROL
                                           SYNCHRONIZE
                                           FILE_GENERIC_READ
                                           FILE_GENERIC_WRITE
                                           FILE_GENERIC_EXECUTE
                                           FILE_READ_DATA
                                           FILE_WRITE_DATA
                                           FILE_APPEND_DATA
                                           FILE_READ_EA
                                           FILE_WRITE_EA
                                           FILE_EXECUTE
                                           FILE_READ_ATTRIBUTES
                                           FILE_WRITE_ATTRIBUTES

     AUTORITE NT\Système:(accès spécial :)
                         READ_CONTROL
                         SYNCHRONIZE
                         FILE_GENERIC_READ
                         FILE_GENERIC_WRITE
                         FILE_GENERIC_EXECUTE
                         FILE_READ_DATA
                         FILE_WRITE_DATA
                         FILE_APPEND_DATA
                         FILE_READ_EA
                         FILE_WRITE_EA
                         FILE_EXECUTE
                         FILE_READ_ATTRIBUTES
                         FILE_WRITE_ATTRIBUTES

     BUILTIN\Utilisateurs:R
     Tout le monde:(accès spécial :)
                   READ_CONTROL
                   SYNCHRONIZE
                   FILE_GENERIC_READ
                   FILE_READ_DATA
                   FILE_READ_EA
                   FILE_READ_ATTRIBUTES
-------------
Sorry, it's a very long data and I can't really say if it's ok or not.
Why such as complexity ?
I understand the DENY FILE_EXECUTE (It's the unix philosophy for file creation)
I don't understand NULL SID DENY - and how it's translated in getfacl.
Now if I compare cacls xx created by cmd they are same in bash and cmd.
Now if I compare getfacl (more readable) for x and of xx, I have :
$ getfacl.exe x
# file: x
# owner: user
# group: Aucun
user::rw-
group::r--
group:root:rwx                          #effective:rw-
group:Utilisateurs authentifiés:rwx     #effective:rw-
group:Système:rwx                      #effective:rw-
group:Utilisateurs:r-x                  #effective:r--
mask:rw-
other:r--

$ getfacl.exe xx
# file: xx
# owner: Administrateurs
# group: Aucun
user::rwx
group::---
group:Utilisateurs authentifiés:rwx
group:Système:rwx
group:Utilisateurs:r-x
mask:rwx
other:---

All that to say, ACLs affected to file are may be surprising but work A LITTLE BIT, yes more ...
But in some cases NOT.
In my cygwin application, sometimes I fall in a situation where I am obliged to reorder the ACEs
to continue correctly. I say obliged and it's the first problem. Who create this situation ?
Always I have seen a NULL SID ACE in such a case. That's the reason I don't like it.
I don't know when the problem occur.
I never encounter NULL SID outside of cygwin environment.
Why sometimes in /bin and /lib ... this case occurs.
I try to show a reproductive case of my problem.

Regards



--
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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

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

On Mar  5 18:49, akikij@free.fr wrote:
> Hi, Corinna
> 
> To be clear about my problems about ACL.
> A very simple example to observe.
> 
> I go to the root disk (C:\ or /cygdrive/c upon the system)
> I can't create a file here (normally protected).
> So I use administrator rights to do that with cmd and bash.
> 
> In cmd :
> C:\>echo > xx
> C:\>cacls xx
> C:\xx BUILTIN\Administrateurs:(ID)F
>       AUTORITE NT\Système:(ID)F
>       BUILTIN\Utilisateurs:(ID)R
>       AUTORITE NT\Utilisateurs authentifiés:(ID)C
> 
> Sorry I am french, but I say Ok why not.

No worries, my french isn't very good, but the group names are
easily understood.

> 
> In bash :
> user@HOST /cygdrive/c -- my prompt bash not repeated after
> $ echo > x
> $ cacls x

Pleae don't use cacls.  Use icacls instead.  Cacls output is much less
readable and, above all, missing important details.  Yeah, icacls is
buggy, but I know what to ignore there ;)

> [...]
> Sorry, it's a very long data and I can't really say if it's ok or not.

It is correct.  Icacls output would have been shorter.

> Why such as complexity ?

It's not overly complex, but admittedly, it's not yet really documented.
Quoting the source code comment:

============================================================================
/* How does a correctly constructed new-style Windows ACL claiming to be a
   POSIX ACL look like?

   - NULL deny ACE (special bits, CLASS_OBJ).

   - USER_OBJ deny.  If the user has less permissions than the sum of CLASS_OBJ
     (or GROUP_OBJ if CLASS_OBJ doesn't exist) and OTHER_OBJ, deny the excess
     permissions so that group and other perms don't spill into the owner perms.

       USER_OBJ deny ACE   == ~USER_OBJ & (CLASS_OBJ | OTHER_OBJ)
     or
       USER_OBJ deny ACE   == ~USER_OBJ & (GROUP_OBJ | OTHER_OBJ)

   - USER deny.  If a user has more permissions than CLASS_OBJ, or if the
     user has less permissions than OTHER_OBJ, deny the excess permissions.

       USER deny ACE       == (USER & ~CLASS_OBJ) | (~USER & OTHER_OBJ)

   - USER_OBJ  allow ACE
   - USER      allow ACEs

   The POSIX permissions returned for a USER entry are the allow bits alone!

   - GROUP{_OBJ} deny.  If a group has more permissions than CLASS_OBJ,
     or less permissions than OTHER_OBJ, deny the excess permissions.

       GROUP{_OBJ} deny ACEs  == (GROUP & ~CLASS_OBJ)

   - GROUP_OBJ  allow ACE
   - GROUP      allow ACEs

   The POSIX permissions returned for a GROUP entry are the allow bits alone!

   - 2. GROUP{_OBJ} deny.  If a group has less permissions than OTHER_OBJ,
     deny the excess permissions.

       2. GROUP{_OBJ} deny ACEs  == (~GROUP & OTHER_OBJ)

   - OTHER_OBJ  allow ACE

   Rinse and repeat for default ACEs with INHERIT flags set.

   - Default NULL deny ACE (S_ISGID, CLASS_OBJ). */
============================================================================

The comment still uses the old Solaris macro names, sorry.  Basically
the NULL deny ACE serves two purposes:

- An ACL starting with a NULL deny SID is immediately recognized as
  a Cygwin POSIX ACL.  That leads to speed advantages because in
  contrast to a non-Cygwin ACL the effective permissiosns don't have
  to be computed the hard way.  A POSIX ACL always transports the full
  permission set including effective perms.

- The NULL deny SID also transports information.  It contains the
  special POSIX permission bits (S_ISVTX, S_ISGID, S_ISUID) as well
  as the POSIX ACL MASK value (CLASS_OBJ == Solaris name for MASK).

So the MASK value is in the NULL deny ACE.  And here's where the other
DENY ACEs come into the picture:  In a Cygwin ACL, the allow ACE for a
trustee contains the *real* perms, otherwise we had no way to reflect
the POSIX ACL correctly.  So the *deny* ACE for a trustee allows to
create the effective perms.  Example:

    real group perms:  r-x
    mask:              rw-
--> effective perms:   r--

Given that the ACE for the group reflects the real perms (r-x)
a deny ACE has to be added to disallow the execute perms.

Make sense?

> All that to say, ACLs affected to file are may be surprising but work A LITTLE BIT, yes more ...
> But in some cases NOT.

This is what I need to know.  What *exactly* doesn't work?

> In my cygwin application, sometimes I fall in a situation where I am
> obliged to reorder the ACEs to continue correctly. I say obliged and
> it's the first problem. Who create this situation ?  Always I have
> seen a NULL SID ACE in such a case. That's the reason I don't like it.

The NULL ACE is very likely not the problem.  I must know what you
try and what you expect, and how Cygwin fails in this scenario.
Please don't touch the ACL using WIndows tools.  And for this
report, please don't touch the ACL at all.  I need to know how it
has been created and what the effect is.


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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[akikij]

Hi, Corinna

Here an example of one problematic ACL
Here on /etc directory (here on remote system)

$ cacls .
...\ws\njcyg\etc NULL SID:(DENY)(accès spécial :)
                                READ_CONTROL

                       <Domaine du compte introuvable>F
                       <Domaine du compte introuvable>R
                       Tout le monde:R
                       NULL SID:(OI)(CI)(IO)(DENY)(accès spécial :)
                                            READ_CONTROL

                       CREATEUR PROPRIETAIRE:(OI)(CI)(IO)F
                       GROUPE CREATEUR:(OI)(CI)(IO)R
                       Tout le monde:(OI)(CI)(IO)R

$ getfacl .
# file: .
# owner: Unknown+User
# group: Unknown+Group
user::rwx
group::r-x
other:r-x
default:user::rwx
default:group::r-x
default:other:r-x

$ icacls .
. NULL SID:(DENY)(Rc,S)
  S-1-5-21-1315901005-2739448750-426064240-1000:(F)
  S-1-5-21-1315901005-2739448750-426064240-513:(RX)
  Tout le monde:(RX)
  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S)
  CREATEUR PROPRIETAIRE:(OI)(CI)(IO)(F)
  GROUPE CREATEUR:(OI)(CI)(IO)(RX)
  Tout le monde:(OI)(CI)(IO)(RX)

When I get Security Tab for this directory,
Windows returns a popup message "Authorizations on etc unordered, some entries may be skipped"
After answering OK, a new panel is shown and as I click on Advanced Autorisations
Windows returns a message proposing to order the ACLs.
After ordering, I get :
$ icacls .
. NULL SID:(OI)(CI)(DENY)(Rc,S)
  CREATEUR PROPRIETAIRE:(OI)(CI)(IO)(F)
  GROUPE CREATEUR:(OI)(CI)(IO)(RX)
  S-1-5-21-1315901005-2739448750-426064240-1000:(F)
  S-1-5-21-1315901005-2739448750-426064240-513:(RX)
  Tout le monde:(OI)(CI)(RX)

getfacl . is unchanged
I don't know which ACLs are or not skipped.
But at a moment of my application, I get a permission denied not for /etc (here an example),
but for another object with analog properties.
Today, I am obliged to return to 2.3 version to keep my application operational.

Regards


--
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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

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

On Mar  7 20:12, akikij@free.fr wrote:
> Hi, Corinna
> 
> Here an example of one problematic ACL
> Here on /etc directory (here on remote system)
> [...]
> # file: .
> # owner: Unknown+User
> # group: Unknown+Group
> user::rwx
> group::r-x
> other:r-x
> default:user::rwx
> default:group::r-x
> default:other:r-x
> 
> $ icacls .
> . NULL SID:(DENY)(Rc,S)
>   S-1-5-21-1315901005-2739448750-426064240-1000:(F)
>   S-1-5-21-1315901005-2739448750-426064240-513:(RX)
>   Tout le monde:(RX)
>   NULL SID:(OI)(CI)(IO)(DENY)(Rc,S)
>   CREATEUR PROPRIETAIRE:(OI)(CI)(IO)(F)
>   GROUPE CREATEUR:(OI)(CI)(IO)(RX)
>   Tout le monde:(OI)(CI)(IO)(RX)

I assume your machines are not in a domain?  The SIDs of that user on
the remote machine are unknown to Cygwin.  For the time being, Cygwin
can't automatically fetch SIDs on remote shares unless you're using
Active Directory.

To fix that locally you have to create /etc/passwd and /etc/group
entries for the remote accounts using `mkpasswd -l <remote machine name>'
and `mkgroup -l <remote machein name>'.  Other than that, the above
SID and it's evaluation via getfacl are perfectly valid.

> When I get Security Tab for this directory,
> Windows returns a popup message "Authorizations on etc unordered, some entries may be skipped"
> After answering OK, a new panel is shown and as I click on Advanced Autorisations
> Windows returns a message proposing to order the ACLs.
> After ordering, I get :

Again, don't do that.  What do you want to do *exactly*?  Do you want to
change the owner and group of the file?  If so, use Cygwin's chown,
please.  Never rearrange Cygwin ACLs using non-Cygwin tools if you want
them to stay functional for the reasons outlined in my previous replies.


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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Erik Soderquist]

I'm having a similar issue with strange acl results... I wish I knew
which update triggered this, but I'd ignored and/or worked around
it...

I can reproduce it with the following:

user@localhost ~
$ touch /tmp/foo

user@localhost ~
$ chmod 700 /tmp/foo

user@localhost ~
$ echo foo>/tmp/foo
-bash: /tmp/foo: Permission denied

user@localhost ~
$ ls -la /tmp
total 20
drwxrwxrwx+ 1 user Administrators 0 Apr 29 11:42 .
dr-xrwxr-x+ 1 Administrators  Administrators 0 Mar  9 17:00 ..
-rwx------+ 1 user Domain Users   0 Apr 29 11:42 foo


result of the acl commands, as I've seen them requested are:

user@localhost /tmp
$ cacls foo
C:\cygwin64\tmp\foo NewDomain\user:(DENY)(special access:)
                                              FILE_READ_DATA
                                              FILE_WRITE_DATA
                                              FILE_APPEND_DATA
                                              FILE_READ_EA
                                              FILE_WRITE_EA
                                              FILE_DELETE_CHILD
                                              FILE_WRITE_ATTRIBUTES

                    NewDomain\user:F
                    NewDomain\user:(special access:)
                                              READ_CONTROL
                                              SYNCHRONIZE
                                              FILE_GENERIC_READ
                                              FILE_GENERIC_WRITE
                                              FILE_READ_DATA
                                              FILE_WRITE_DATA
                                              FILE_APPEND_DATA
                                              FILE_READ_EA
                                              FILE_WRITE_EA
                                              FILE_READ_ATTRIBUTES
                                              FILE_WRITE_ATTRIBUTES

                    NewDomain\Domain Users:(DENY)(special access:)
                                           FILE_READ_DATA
                                           FILE_WRITE_DATA
                                           FILE_APPEND_DATA
                                           FILE_READ_EA
                                           FILE_WRITE_EA
                                           FILE_DELETE_CHILD
                                           FILE_WRITE_ATTRIBUTES

                    OldDomain\Domain Users:(DENY)(special access:)
                                      FILE_READ_DATA
                                      FILE_WRITE_DATA
                                      FILE_APPEND_DATA
                                      FILE_READ_EA
                                      FILE_WRITE_EA
                                      FILE_DELETE_CHILD
                                      FILE_WRITE_ATTRIBUTES

                    NewDomain\Domain Users:(special access:)
                                           READ_CONTROL
                                           SYNCHRONIZE
                                           FILE_GENERIC_READ
                                           FILE_GENERIC_WRITE
                                           FILE_READ_DATA
                                           FILE_WRITE_DATA
                                           FILE_APPEND_DATA
                                           FILE_READ_EA
                                           FILE_WRITE_EA
                                           FILE_READ_ATTRIBUTES
                                           FILE_WRITE_ATTRIBUTES

                    BUILTIN\Administrators:(special access:)
                                           READ_CONTROL
                                           SYNCHRONIZE
                                           FILE_GENERIC_READ
                                           FILE_GENERIC_WRITE
                                           FILE_READ_DATA
                                           FILE_WRITE_DATA
                                           FILE_APPEND_DATA
                                           FILE_READ_EA
                                           FILE_WRITE_EA
                                           FILE_READ_ATTRIBUTES
                                           FILE_WRITE_ATTRIBUTES

                    OldDomain\Domain Users:(special access:)
                                      READ_CONTROL
                                      SYNCHRONIZE
                                      FILE_GENERIC_READ
                                      FILE_GENERIC_WRITE
                                      FILE_READ_DATA
                                      FILE_WRITE_DATA
                                      FILE_APPEND_DATA
                                      FILE_READ_EA
                                      FILE_WRITE_EA
                                      FILE_READ_ATTRIBUTES
                                      FILE_WRITE_ATTRIBUTES

                    Everyone:(special access:)
                             READ_CONTROL
                             SYNCHRONIZE
                             FILE_READ_ATTRIBUTES




user@localhost /tmp
$ icacls foo
foo NewDomain\user:(DENY)(W,RD,REA,DC)
    NewDomain\user:(F)
    NewDomain\user:(R,W)
    NewDomain\Domain Users:(DENY)(W,RD,REA,DC)
    OldDomain\Domain Users:(DENY)(W,RD,REA,DC)
    NewDomain\Domain Users:(R,W)
    BUILTIN\Administrators:(R,W)
    OldDomain\Domain Users:(R,W)
    Everyone:(Rc,S,RA)

Successfully processed 1 files; Failed processing 0 files


I don't understand why there is a DENY at all rather than simply
removing the Allow permissions, nor do I understand why the user, who
is owner of the file and has rwx for it, is getting a DENY at all.

-- Erik

--
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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

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

On Apr 29 12:03, Erik Soderquist wrote:
> I'm having a similar issue with strange acl results... I wish I knew
> which update triggered this, but I'd ignored and/or worked around
> it...
> 
> I can reproduce it with the following:
> 
> user@localhost ~
> $ touch /tmp/foo
> 
> user@localhost ~
> $ chmod 700 /tmp/foo
> 
> user@localhost ~
> $ echo foo>/tmp/foo
> -bash: /tmp/foo: Permission denied
> 
> user@localhost ~
> $ ls -la /tmp
> total 20
> drwxrwxrwx+ 1 user Administrators 0 Apr 29 11:42 .
> dr-xrwxr-x+ 1 Administrators  Administrators 0 Mar  9 17:00 ..
> -rwx------+ 1 user Domain Users   0 Apr 29 11:42 foo
> 
> 
> result of the acl commands, as I've seen them requested are:
> 
> user@localhost /tmp
> $ cacls foo
> [...]
> user@localhost /tmp
> $ icacls foo
> foo NewDomain\user:(DENY)(W,RD,REA,DC)
>     NewDomain\user:(F)
>     NewDomain\user:(R,W)
>     NewDomain\Domain Users:(DENY)(W,RD,REA,DC)
>     OldDomain\Domain Users:(DENY)(W,RD,REA,DC)
>     NewDomain\Domain Users:(R,W)
>     BUILTIN\Administrators:(R,W)
>     OldDomain\Domain Users:(R,W)
>     Everyone:(Rc,S,RA)

Can you, by any chance, also send the output of `cd /tmp; icacls .'?


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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Erik Soderquist]

On Mon, May 30, 2016 at 6:35 AM, Corinna Vinschen wrote:
>
> Can you, by any chance, also send the output of `cd /tmp; icacls .'?
>

Unfortunately no, corporate machine, and was replaced less than a week
ago.  The new machine does not have the same issue, though I have not
tested (and probably won't be able to test) the upgrade scenarios that
seem to be associated with this issue unless I stumble upon it on a
different machine.

-- Erik

--
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: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

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

On May 30 16:50, Erik Soderquist wrote:
> On Mon, May 30, 2016 at 6:35 AM, Corinna Vinschen wrote:
> >
> > Can you, by any chance, also send the output of `cd /tmp; icacls .'?
> >
> 
> Unfortunately no, corporate machine, and was replaced less than a week
> ago.  The new machine does not have the same issue, though I have not
> tested (and probably won't be able to test) the upgrade scenarios that
> seem to be associated with this issue unless I stumble upon it on a
> different machine.

Too bad, but that's life.


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 --]