Mail Archives: cygwin-developers/2002/12/05/22:29:45
Corinna,
There is a thread on the cygwin list
http://cygwin.com/ml/cygwin/2002-11/msg01127.html
where ntsec is blamed for permission troubles with
non cygwin applications.
At first sight that seems far fetched, but see below.
The only mechanism I can imagine are the inheritances
set by Cygwin on directories.
In the case reported on the list, the Windows owner sid
(in the process token) is Administrators, but under Cygwin
internal_getlogin sets the owner sid to the user sid.
So I tried an experiment where a user creates a file with
a Windows application (or Cygwin nontsec) in a directory
created by another user with ntsec.
I now believe that there IS a possibility for trouble,
although it does not explain all the complaints in
the message referenced above.
This is on NT4
The directory is owned by me. It was created with ntsec.
$ getfacl .
# file: .
# owner: PHumblet
# group: Domain Admins
user::rwx
group::rwx
other::rwx
mask::rwx
default:user::rwx
default:group::rwx
default:other::rwx
Now I login as unprivileged user testuser
and I "touch testuser_ntsec" with ntsec
$ getfacl testuser_ntsec
# file: testuser_ntsec
# owner: testuser
# group: None
user::rw-
group::rw-
other::rw-
mask::rw-
All is well. The ACL is completely determined by Cygwin.
Now the same testuser changes to nontsec and
"touch testuser_nontsec"
Windows applications see the same default behavior.
$ getfacl testuser_nontsec
# file: testuser_nontsec
# owner: testuser
# group: None
user::---
group::---
other::rwx
mask::---
user:PHumblet:rwx
group:Domain Admins:rwx
The ACL is completely determined by the inheritance rules.
User testuser has NO specific ACE, although he is the owner.
Only the "other" permissions would apply to him. If "other"
has no read access, the owner won't either.
Although there is an entry in the file acl for the directory
owner and his group, this isn't helpful to the file owner.
Also the fact that the ACL now contains unrelated ACEs makes
the modes in stat and ls -l unreliable.
Brainstorming
*************
- What behavior are we trying to achieve?
- If we do not set any inheritances on directories and a file is
created, by default the user (or Administrators) and System
have full access, period. That's clearly worse than today.
- Should we set inheritance rights for "well_known_creator_owner_sid"
(and not for the directory owner sid)?
For the group, define similarly a "well_known_creator_group_sid"
(S-1-3-1).
That is, we could insert these special sids in INHERIT_ONLY ACEs on
directories, mirroring the owner/group/everyone, both deny and
allow. I have verified that the inherited ACEs have the correct
order, even if it isn't canonical.
- Or should we simply give INHERIT_ONLY full access to Everyone?
(probably least likely to generate complaints, but least secure).
One advantage of this last approach is that such an ACE could easily
be detected and suppressed in the getacl code, and "normal" cygwin
directories would stop having a "+" in ls -l.
- ???
A related matter is that the getfacl output for "." above is incorrect.
For example, the line "default:user::rwx"
should be "default:user:PHumblet:rwx"
i.e. apply to a specific user although PHumblet is the owner.
This is easily seen from the output of "getfacl testuser_nontsec"
An unnamed user line "default:user::abc"
should only be generated when well_known_creator_owner_sid is
present. Similarly for group.
Following an unrelated problem using setfacl, I have looked more into
the acl functions and noticed difference with Sun on two points:
the number of colons and on the input formats
See below. Comments on right side. "midi" is a Sun.
1-midi$ getfacl Pierre
# file: Pierre
# owner: humblet
# group: cm
user::rwx
group::--x #effective:--x
mask:--x <=== ONLY ONE COLON IN OUTPUT
other:--x <=== ONLY ONE COLON IN OUTPUT
1-midi$ setfacl -s u::rwx,g::--x,o::--x Pierre/
use only 1 colon for mask and other entries. <=== ONLY ONE COLON
1-midi$ setfacl -s u::rwx,g::--x,o:--x Pierre/ <=== WORKS ON SUN
/> setfacl -s u::rwx,g::--x,o:--x a.exe <=== BUT NOT ON CYGWIN
setfacl: missing entries.
/> setfacl -s u::rwx,g::--x,o::--x a.exe <=== EVEN WITH ::
setfacl: missing entries.
I can take a stab at some of this after we finish the internal
passwd business and converge on what to do about inheritances.
Pierre
- Raw text -