Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Mon, 16 Jul 2001 00:44:16 +0200 From: Corinna Vinschen To: cygdev Subject: NTSEC users: Please test Message-ID: <20010716004416.O25442@cygbert.vinschen.de> Reply-To: cygdev Mail-Followup-To: cygdev Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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.