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
