NTSEC users: Please test

Corinna Vinschen vinschen@redhat.com
Sun Jul 15 15:44:00 GMT 2001


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@cygwin.com
Red Hat, Inc.



More information about the Cygwin-developers mailing list