* Issues with ACL settings after updating to the latest cygwin.dll - correction
[not found] <2119166713.121814507.1457103633265.JavaMail.root@zimbra93-e16.priv.proxad.net>
@ 2016-03-04 15:43 ` akikij
2016-03-05 10:01 ` Corinna Vinschen
2016-03-05 17:49 ` akikij
0 siblings, 2 replies; 10+ messages in thread
From: akikij @ 2016-03-04 15:43 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-03-04 15:43 ` Issues with ACL settings after updating to the latest cygwin.dll - correction akikij
@ 2016-03-05 10:01 ` Corinna Vinschen
2016-03-05 17:49 ` akikij
1 sibling, 0 replies; 10+ messages in thread
From: Corinna Vinschen @ 2016-03-05 10:01 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-03-04 15:43 ` Issues with ACL settings after updating to the latest cygwin.dll - correction akikij
2016-03-05 10:01 ` Corinna Vinschen
@ 2016-03-05 17:49 ` akikij
2016-03-06 16:38 ` Corinna Vinschen
2016-03-07 19:12 ` akikij
1 sibling, 2 replies; 10+ messages in thread
From: akikij @ 2016-03-05 17:49 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-03-05 17:49 ` akikij
@ 2016-03-06 16:38 ` Corinna Vinschen
2016-03-07 19:12 ` akikij
1 sibling, 0 replies; 10+ messages in thread
From: Corinna Vinschen @ 2016-03-06 16:38 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-03-05 17:49 ` akikij
2016-03-06 16:38 ` Corinna Vinschen
@ 2016-03-07 19:12 ` akikij
2016-03-08 9:02 ` Corinna Vinschen
1 sibling, 1 reply; 10+ messages in thread
From: akikij @ 2016-03-07 19:12 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-03-07 19:12 ` akikij
@ 2016-03-08 9:02 ` Corinna Vinschen
[not found] ` <CACoZoo385sv6iWTQspaNbbrbF5LtbWSNvFmViTTVTHKrtPO1gQ@mail.gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Corinna Vinschen @ 2016-03-08 9:02 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
[not found] ` <CACoZoo385sv6iWTQspaNbbrbF5LtbWSNvFmViTTVTHKrtPO1gQ@mail.gmail.com>
@ 2016-04-29 16:03 ` Erik Soderquist
2016-05-30 16:33 ` Corinna Vinschen
0 siblings, 1 reply; 10+ messages in thread
From: Erik Soderquist @ 2016-04-29 16:03 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-04-29 16:03 ` Erik Soderquist
@ 2016-05-30 16:33 ` Corinna Vinschen
2016-05-31 8:54 ` Erik Soderquist
0 siblings, 1 reply; 10+ messages in thread
From: Corinna Vinschen @ 2016-05-30 16:33 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-05-30 16:33 ` Corinna Vinschen
@ 2016-05-31 8:54 ` Erik Soderquist
2016-05-31 21:08 ` Corinna Vinschen
0 siblings, 1 reply; 10+ messages in thread
From: Erik Soderquist @ 2016-05-31 8:54 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
2016-05-31 8:54 ` Erik Soderquist
@ 2016-05-31 21:08 ` Corinna Vinschen
0 siblings, 0 replies; 10+ messages in thread
From: Corinna Vinschen @ 2016-05-31 21:08 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-05-31 9:35 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <2119166713.121814507.1457103633265.JavaMail.root@zimbra93-e16.priv.proxad.net>
2016-03-04 15:43 ` Issues with ACL settings after updating to the latest cygwin.dll - correction akikij
2016-03-05 10:01 ` Corinna Vinschen
2016-03-05 17:49 ` akikij
2016-03-06 16:38 ` Corinna Vinschen
2016-03-07 19:12 ` akikij
2016-03-08 9:02 ` Corinna Vinschen
[not found] ` <CACoZoo385sv6iWTQspaNbbrbF5LtbWSNvFmViTTVTHKrtPO1gQ@mail.gmail.com>
2016-04-29 16:03 ` Erik Soderquist
2016-05-30 16:33 ` Corinna Vinschen
2016-05-31 8:54 ` Erik Soderquist
2016-05-31 21:08 ` Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).