Re: NTFS inherited permissions bug on W2K

From: Greg Corey (gregc@TARASOFTWARE.COM)
Date: 10/10/01 

Message-ID:  <840E6FA07F28D511981200A0C9FB45231B4FE2@CYCLONE>
Date:         Wed, 10 Oct 2001 14:32:28 -0500
From: Greg Corey <gregc@TARASOFTWARE.COM>
Subject:      Re: NTFS inherited permissions bug on W2K
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Since I'm a Windows 2000 track MCSE, I'll take a stab at this as nobody
seems to have completely killed this horse yet. Here's how permissions
inheritance works (note this is also consistent with everything I've seen
from Microsoft about how it should work):

1. A file (or directory) gets inherited permissions (and compression
attributes) from its parent at time of creation.

2. The file can have permissions explicitly defined on it in addition to
those inherited.

3. If the file is copied or "moved" to a different volume (which is really a
copy+delete), all permissions and compression settings are lost and new
inheritances are obtained from the NEW parent folder -- as if it were a new
file (because it is).

4. If the file is moved to another location on the same NTFS volume, only
the directory pointers are changed in the file system -- the file data
doesn't move or change. This means all rights, both inherited and
explicitly applied, are maintained (as is compression status). The rights
that have been inherited are still marked as inherited on FILES that are
moved, but the rights become explicit rights on the top level folder. You
might argue that the inherited rights on files directly moved (as opposed to
files under a directory that moves) should become explicit as well and
THAT'S the bug -- but that's a pretty weak argument (see my next point for
why). If you move only directories, the underlying files will correctly
reflect inheritance because the rights they inherit should be the same as
the (now) explicit rights of the moved parent.

5. Windows 2000 is designed to MAINTAIN file and folder permissions that are
explicitly defined (not inherited) if the parent's permissions are changed
unless you deliberately reset those permissions and enable inheritance (in
the advanced settings). A change to the parent's rights causes a refresh of
all INHERITED rights of subfolders and files (as it should) on objects that
have inheritance turned on. Again, rights a folder inherits from it's
former parent folder become explicit rights when the folder moves. The
rights of files underneath it still reflect inheritance and will inherit (as
they should) the permissions of the parent if the parent's permissions
change. That the files directly moved still reflect inheritance also makes
some sense -- if you didn't set permissions explicitly before, you probably
won't want to now. The directly moved files maintain pre-move permissions
only until you change the parent's permissions -- at which point presumably
you expect that change to affect all files underneath with inherited
permissions. Microsoft would create more confusion if the move process
turned off inheritance and assigned explicit permissions on files that have
previously inherited all rights and never had explicit rights defined. That
would be a problem in and of itself. If Microsoft reset the rights of
directly moved files to those of the new folder immediately to avoid that
problem, it would be vastly inconsistent with expected and documented
behavior (that files and folders moved in-volume retain the original
rights).

 -- Greg

============================================================================
Delivery co-sponsored by Trend Micro, Inc.
============================================================================
BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000
Earn 5% rebate on licenses purchased for Trend Micro ScanMail for
Microsoft Exchange 2000 between October 1 and November 16. ScanMail
ensures 100% scanning of inbound and outbound traffic and provides
remote software management. For program details or to download your
30-day FREE evaluation copy:
http://www.antivirus.com/banners/tracking.asp?si=53&BI;=245&UL;=http://www.ant
ivirus.com/smex2000_rebate

Relevant Pages

  • Re: ADAM And ACLs
    ... The ACLs for the OU which is the parent of the object below are: ... Effective Permissions on this object are: ... SPECIAL ACCESS ... for the naming context and is usually present by inheritance, ...
    (microsoft.public.windows.server.active_directory)
  • Re: cumulative permissions?
    ... You have to take in inheritance and other factors. ... Where "back in the day" any Deny on an ACL for a secprin resulted in an overall Deny, that is no longer the case due to how the ACLs are handled now. ... In the end, if you come through a share, you have to find the most rights granted via the share for the sec prin and the most rights granted via NTDS for the sec prin and then take the minimum of the two. ... You have the permissions directly granted to it but there are also some hardcoded perms, specifically the ability to change the permissions anytime you want. ...
    (microsoft.public.security)
  • Re: Permissions resetting in Blocked Inheritance OUs
    ... Your director shouldn't have enhanced rights in the directory and that is what causes that, he should have a normal user account. ... If i leave the account for a little while and go back to it the PA's account has been replaced with an unrecognised account with just a SID and different permissions. ... I have tested with other accounts and it only seems to affect accounts that are in OU's that have blocked inheritance set in Group Policy. ...
    (microsoft.public.windows.server.active_directory)
  • Re: NTFS inherited permissions bug on W2K
    ... NTFS inherited permissions bug on W2K ... >> Inheritance has always been present in NT. ... >actually copied to the inherited objects' ACLs). ...
    (NT-Bugtraq)
  • Re: Permissions resetting in Blocked Inheritance OUs
    ... If the ACL that is on the AdminSDHolder object is ... Delegated permissions are not available and inheritance is automatically ... "You do not have sufficient permissions in the Domain" error message occurs ... This user account is in an OU that has Blocked ...
    (microsoft.public.windows.server.active_directory)