Mail Archives: cygwin-developers/2001/07/30/04:15:29
On Mon, Jul 30, 2001 at 01:49:27AM -0400, Charles Wilson wrote:
> Charles Wilson wrote:
>
>
> >
> > Changes by: corinna AT sources DOT redhat DOT com 2001-07-09 02:02:42
> > Modified files:
> > winsup/cygwin : ChangeLog security.cc
> > Log message:
> > * security.cc (alloc_sd): Don't set inheritance attribute for
> > permissions given to directories.
> >
>
> Well, this is definitely the culprit; this change plus W2K/NTFS. I
I still doubt that that is the problem for two reasons.
First, I can't reproduce the below behaviour in a NTFS dir (which
isn't that evident, though). The directories have permissions
700 as the testsuite creates them, the subordered files have
644 permissions. Both shouldn't result in a problem to delete
the files.
And second, as I already mentioned, the autoconf-2.52 testsuite
fails even in a /tmp on _FAT_ which is definitely not ntsec related.
> don't get the problematic behavior on NT/NTFS. However, I know that
> Corinna put this in for a reason -- but I don't remember what it was. :-(
The reason is the following:
Unfortunately, the CreateFile call has no SECURITY_DESCRIPTOR
parameter for the file permissions similar to the open()/creat()
`mode' parameter in U*X. For that reason files are created either
by giving them a default ACL or, if the parent directory propagates
ACEs, by giving them the inherited ACEs from the parent dir.
To give a file or dir the correct permissions, fhandler_base::open()
has to call CreateFile() first, then it calls set_file_attibutes()
which in turn creates the ACL if ntsec is on.
The problem occurs when a user creates a file in a directory which
propagates ACEs and which isn't owned by him. The ACEs are copied
from the parent which contains the permission to change the
permissions only for the owner... of the directory! Which results
in the schizophrenic situation that the ACL only contains ACEs
for the owner of the _directory_ but no ACE for the owner of the
_file_! But... if the owner of the file has no ACE he has obviously no
permission to change permissions. Which in turn results in a failing
call to set_file_attributes() under Cygwin. So the ACL for the just
created file remains unchangable wrong.
If a folder doesn't propagate ACLs, the file gets default permissions
which are typically set to something like "Owner:Full Control,
System:Full Control" which allows the owner to create an ACL for
his own file.
Is that clearly described?
Corinna
>
> Anyway, check this out (under cygwin1-20010728.dll):
>
>
> $ cd /tmp
> $ mkdir a
> $ getfacl a
>
> # file: a
> # owner: 1000
> # group: 513
> user::rwx
> user:500:rwx
> group::rwx
> group:544:rwx
> group:545:rwx
> mask::rwx
> other::r-x
> default:user:500:rwx
> default:group:544:rwx
> default:group:545:rwx
> default:mask::---
>
> $ cd a
> $ mkdir b
> $ getfacl b
>
> # file: b
> # owner: 1000
> # group: 513
> user::---
> user:500:rwx
> group::---
> group:544:rwx
> group:545:rwx
> mask::---
> other::---
> default:user:500:rwx
> default:group:544:rwx
> default:group:545:rwx
> default:mask::---
>
> $ touch c
> $ getfacl c
>
> # file: c
> # owner: 1000
> # group: 513
> user::---
> user:500:rwx
> group::---
> group:544:rwx
> group:545:rwx
> mask::---
> other::---
>
> I'm not sure if the answer is to revert Corinna's patch, or to add more
> logic to the file/directory creation logic. Any comments?
>
> --Chuck
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -