Re: Inheritance of permissions after moving within volume



In my opinion you have mentioned one of the larger messes
existing in the current Windows NTFS semantics, and, other
than the workarounds you mention there is no good solution.

I find it to be the most common scenario that when moving
a filesystem object one wants it to have the permissions of
the moved-into target location, that is, have no trace of the
original permissions, inherited or explicit.

The way it is the intra-partition moved object will have the
explicit permissions of the original and initially the inherited
of the original location and these inherited will get changed
at some future time, which is not predictable as it must be
"triggered" by modification of the target location parental
inheritance specification (such as adding a temp inheritable
and then removing it).

This IMO is overdue for correction.
It is my contention that the intermediate state before the
inherited permissions have been updated is both an error
condition and a security violation. It is also my belief that
for almost all cases retaining the original explict and then
applying the target location inherited make zero administrative
sense.

I would love to see someone from MS answer your need
with a simple solution, and also defend the existing semantics
remaining as they are, as during the past two major generations
of Windows' betas I have been unable to get an MS person to
seriously reevaluate the (in)appropriateness of the current
semantics.

Roger Abell
MVP Windows : Security

"Demis" <news@xxxxxxx> wrote in message
news:7suqo15i4a25bebi8ed4p2kot3u4e8p00v@xxxxxxxxxx
> Hello all
>
> Problem is the following:
> When a file is moved from one location to another on the same volume,
> the file retains its permissions.
> This can lead to a mess of permissions on fileservers.
>
> Does somebody know a solution to force the inheritance of permissions
> under these circumstances?
>
> I know there are some workarounds like copy and delete the file or:
> - Prior to moving the file, clear the Allow inheritable permissions
> from the parent to propagate to this object check box.
> - Click Copy to copy the current permissions to the object.
> - Move the file or folder to a different location on the same volume.
> - Click Allow inheritable permissions from the parent to propagate to
> this object.
>
> But I do not want to expect this from normal users.
>
> Thanks,
> Demis
>


.



Relevant Pages

  • Re: Inheritance of permissions after moving within volume
    ... The problem is that while moving a file within volumes only the ... >a filesystem object one wants it to have the permissions of ... >the moved-into target location, that is, have no trace of the ... >> Does somebody know a solution to force the inheritance of permissions ...
    (microsoft.public.win2000.security)
  • Re: Inheritance of permissions after moving within volume
    ... straightening out the permissions when necessary, ... issue up in each Windows beta cycle, ... >>applying the target location inherited make zero administrative ... >>> Does somebody know a solution to force the inheritance of permissions ...
    (microsoft.public.win2000.security)
  • 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: 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: 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)