Mail Archives: cygwin-developers/2001/07/15/18:44:23
Hi all,
I have applied a patch to ntsec which changes the behaviour related to
deletion of files and directories.
If you check how the permission to delete are handled by NTFS, you
will found a horrible different handling than in POSIX systems.
Briefly the behaviour is the following:
- If a user has DELETE permission given on a file or directory,
he can delete it.
- If a user has no DELETE permission but he has the FILE_DELETE_CHILD
permission on the parent directory, he can delete the file.
The consequence: If a user has delete permission on a file, it's
impossible to refuse this delete permission with the help of the
parent directory's permissions.
In contrast POSIX filesystems handle the delete permissions by the
permissions in the parent directory. If everyone has write and execute
permissions on the parent directory, everyone may delete files in the
directory even if the permissions on the file might disallow that.
This can be restricted to the owner of the file and the owner of the
directory by setting the S_ISVTX bit in the directory permissions.
See `man 2 stat' on Linux:
...
The `sticky' bit (S_ISVTX) on a directory means that a
file in that directory can be renamed or deleted only by
the owner of the file, by the owner of the directory, and
by root.
...
Example:
dir foo has permissions 755
file foo/bar has permissions 666
POSIX: "others" cannot delete foo/bar.
Cygwin: "others" can delete foo/bar since the DELETE permission
is coupled with the write permission.
So the current implementation of delete permissions in ntsec turned
out to be crap. I fully misunderstood the behaviour of the delete
permissions so far. I had some extensive tests and thought about
a way to implement these permissions the POSIX way.
I think I found how to do it and I implemented it now that way:
- The DELETE permission is never used.
- The FILE_DELETE_CHILD permission is only set on directories
if user (or group or others) has write and execute permission.
This reflects the POSIX permission to delete a file or subdirectory
only if w and x bits are both set.
- If S_ISVTX bit should be set the FILE_DELETE_CHILD permission isn't
set for "others" even if they have write and execute bit set. This
seems to match the POSIX behaviour now as close as possible.
The problem with this solution is the testing which might be a bit
tricky. If you switch over to a Cygwin DLL with this code you
could perhaps try what I tried:
- `chmod 755' on a directory which already has 755 permissions.
Will not work since `chmod' is so _clever_ to do nothing
if the requested permissions are the same as the current
permissions.
- Then you could set `chmod 555' on the directory so that
FILE_DELETE_CHILD isn't set for you and you will find that
deleting an existing file with permissions 644 still works.
The already existing file you tried to delete isn't created
with this DLL so it still has the DELETE permission set for
you :-P
OR
You have a bloody lot of user privileges which are typically
set for administrators and/or SYSTEM only.
Ok, the above two (or three, actually) are the cases I already
stumbled over. I hope, somebody is willing to give it a try, though.
Oh, I almost forgot the second change.
I added the ability to create and evaluate the S_ISUID, S_ISGID
and S_ISVTX bits on NTFS as U/Win creates and uses them.
They are created as a special ACE for the NULL SID (S-1-0-0)
in which the FILE_READ_DATA (= S_ISVTX), FILE_WRITE_DATA (= S_ISGID)
and FILE_APPEND_DATA (= S_ISUID) bits are set accordingly.
The ACE is not created if none of these permissions is set.
That means we already can created the setuid and setgid permissions
even if we don't have the ability to use them yet.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -