I know this is about 3 weeks old, but I just now stumbled on it - This isn't correct - first of all, there's always implicit WRITE_DAC for the owner of the object. Owner of something can always change permissions on it. Before any ACEs are checked, if WRITE_DAC is requested, and you're the owner, you get that bit allowed.
Second thing the user could do, if they were determined and could write code, is that the ACL on something can be supplied atomically at creation time - it's one of the parameters to CreateFile. This is really one of the nicer things about the Windows API because you don't have to worry about race conditions between creating something and locking it down, and if you're using restricted tokens - say with Vista services - you'll need to supply an ACL for some things. There are ways to work around some of this, depending on conditions - 1) If the files are located on a share, you can not give the people with access to the share permissions to change permissions on anything in the share. Share permissions are in general confusing and annoying, but this is one case you can use share and file permissions together. This won't stop creating the file with an ACL supplied, but it stops other forms of user mischief. 2) If you want to go to this much trouble, create a service that looks for changes in that directory, and when it finds them, it takes ownership of anything showing up there, and sets an ACL the admin finds appropriate. The user's no longer owner. You'll also lose any information about who created something, unless you log it somehow. Note that this doesn't absolutely work until all the outstanding handles with WRITE_DAC access are closed, but it's unlikely an ordinary user could overcome this. Hope this helps... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of M. Burnett > Sent: Wednesday, January 10, 2007 10:01 AM > To: 'Jim Harrison'; [EMAIL PROTECTED]; [email protected] > Subject: RE: Share and NTFS permissions > > Although the owner has full control by default, you can > prevent owners from changing permissions on files they > create. Do this by denying the CREATOR OWNER user from > changing permissions on a folder and that will propagate to > any new files in that folder. > > But there's a trick to this. When you create this ACL, make > sure it applies to "Subfolders and files only" and not the > folder itself so you don't prevent yourself from changing > permissions on that folder again (you would need another > administrator user to fix it for you). > > I recently wrote about file ownership and other NTFS oddities > on my blog: > http://xato.net/bl/2007/01/04/pointless-permissions/ > > > Mark Burnett > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Harrison > Sent: Tuesday, January 09, 2007 7:14 AM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: Share and NTFS permissions > > That's exactly what "owner" implies. > The resource belongs to them and they have the ability to do > what they will with it. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Friday, January 05, 2007 10:24 AM > To: [email protected] > Subject: RE: Share and NTFS permissions > > We have found an issue with giving full rights to the share: > The NTFS file owner can still change permissions. > > The creator of a file is the owner and has the ability to > change NTFS permissions on that file/folder, regardless of > what the existing NTFS rights are! > This allows the file creator to alter the permissions either > blocking access or giving excess permissions. > > A solution in this case is to create the share with Everyone( > or Authenticated Users/Given group...) Change rights and > Administrators FULL Control. NTFS is then set as desired. > Limiting the share to Change prevents the owner from > modifying NTFS rights if accessing the file through the > share, but leaves everything else. > > Drew Monrad > > All mail to and from this domain is GFI-scanned. >
