Because the effective permissions on a share are the intersection of the file system permissions and the share permissions. So for example, let's say that I had permissions on a shared folder that allowed me to add new files, and gave me read-write-delete on files I created. The file system is going to implicitly give me permission to change permission on things I own.
If I'm an obnoxious user, I create a new directory, fill it up with say pirated music files, and then to keep the pesky admins out, I change the acls to allow me and my friends full control, admins are denied. This creates a problem for the admins. Now if the admins only give me change permissions at the share level, I can't change the permissions after I've created something, which allows me to accomplish something that can't be done at the scope of the file system. This will be enough to keep most users from causing this problem. > -----Original Message----- > From: Jeff Flack [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 12:39 PM > To: De Rienzo, James; David LeBlanc; M. Burnett; Jim > Harrison; [EMAIL PROTECTED]; [email protected] > Subject: RE: Share and NTFS permissions > > WHy are you even bothering w/ SHARE permissions? > > > > --On Monday, February 05, 2007 10:33 AM -0500 "De Rienzo, James" > <[EMAIL PROTECTED]> wrote: > > > Change the file's Ownership to Administrator, and be done with it. > > > > Simple yet effective. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > On Behalf Of David LeBlanc > > Sent: Sunday, February 04, 2007 4:25 PM > > To: 'M. Burnett'; 'Jim Harrison'; [EMAIL PROTECTED]; > > [email protected] > > Subject: RE: Share and NTFS permissions > > > > 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. > >> > > > > > > > > > > > > Jeff Flack, MCSE > [EMAIL PROTECTED] > (585)281-4321 >
