Re: NTFS inherited permissions bug on W2K

From: Martin Maher (gentoo@ASCENT.NET)
Date: 10/10/01 

Message-ID:  <200110092044703.SM00175@peak>
Date:         Tue, 9 Oct 2001 20:43:19 -0400
From: Martin Maher <gentoo@ASCENT.NET>
Subject:      Re: NTFS inherited permissions bug on W2K
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

I think another important thing to consider here is something that Fritz
pointed out rather well, when you "move" a file on NTFS *within* the same
volume ALL that is *moved* is the pointer to the original file. Granted, you
can't see this exposed anywhere, but it is true.

While this may *not* be a bug in the classic definition, it IS a security
detail that has been overlooked/ignored, perhaps because of issues just as
Ben has alluded to - "It wouldn't be as *convenient* to do it now, we'll do
it later when something *really* changes." An easy fix would be to simply
add a modal dialog that asks "Would you like to retain current permissions
or have them adjusted to match the target directory?" Of course, this could
be my Macintosh roots speaking out here. <grin>

The only *new* wrinkle that I see that makes this different from the past is
that under WinNT 4, the permissions on the file in it's *moved to* location
were never changed unless you either - a) went in and made the changes to
the file explicitly; or b) changed an enclosing directory further up the
tree and checked off the (have to agree here) very unintuitive box "Replace
Permissions on Subdirectories." (Personally, I have always thought an
additional choice of something on the order of "Update Current
Subdirectories and Files to Reflect Changes" would be appropriate. It would
negate alot of fiddling using calcs to remove someone like the "Everyone"
user from a tree and NOT do anything else, but I digress)

>From what I can gather under Win2K, if the box indicating inheritance is
checked, it *will* happen automatically as soon as you make some change
upstream.

Martin Maher
System Administrator
Ascent Networking Internet Services

At 19:40 10/9/01 -0400, you wrote:
>> Inheritance has always been present in NT.
>[...]
>> ACLs in NT have always been displayed as explicit, even if they were
>> inherited from the parent directory. The updated ACL editor included
>in NT
>
>While this is true, Win2K adds the "sweep and re-flow" notion: when you
>apply changes to permissions on a directory in Win2K, it actually sweeps
>subdirectories and reapplies inherited/inheritable permissions to
>filesystem objects that reside below that tree (try changing the ACL on
>C:\ and see how long it takes when you hit "Apply" if you don't believe
>me). In NT4 and prior, this re-application did not occur.
>
>The bug being reported here is that when you move an item from one
>directory to another in Win2K, it should sweep and re-flow the
>permissions to that item at that point, because Win2K introduces the
>notion (admittedly an illusion) that the inherited permissions are
>"live" (even though the implementation is that the inherited ACEs are
>actually copied to the inherited objects' ACLs).
>
>For more details, see Keith Brown's "Programming Windows Security", from
>the DevelopMentor series, published I believe by Addison-Wesley.
>
>__
>Ben Cox
>Technical Consultant
>Summa Technologies, Inc.

============================================================================
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: AD User Objects & Permission Inheritance
    ... I went ahead and granted the Account Operators built in group rights on the adminSDholder object according to what I want the OU admins to have. ... I went ahead and enabled inheritance on the> adminSDholder object to verify that this indeed was the cause and 60> minutes ... > later all user objects began to inherit permissions again. ...
    (microsoft.public.win2000.active_directory)
  • 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)
  • 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)
  • Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices
    ... Joerg Schilling wrote: ... > This is of course a kernel bug - but it could be easily fixed. ... Not checking for Write access permissions at this place is a typical mistake ...
    (Linux-Kernel)