Inheritance of permissions after moving within volume

[Demis]

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

 

[Roger Abell [MVP]]

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]

Hi Roger

I fully agree with you. It makes me happy to hear such a statement
from a MVP.
The problem is that while moving a file within volumes only the
reference to that file changes.
This makes sense in case of performance, but not if we want proper
permissions.

A solution would be to change the move procedure to copy and delete,
like it happens when we move files/folders to other volumes.
However, this needs a deep knowledge of the OS.

Kind regards,
Demis

 

[Roger Abell [MVP]]

It is all legacy stuff that needs a redesign.
One can consider hooking specific filesystem actions and then
straightening out the permissions when necessary, but that would
have some real performance impacts.
It really needs to be addressed by MS as a change in behavior
(now that the performance gain from the old semantics is not so
significant compared to modern machines' capacities).

In the meantime, I just recommend to people to copy and delete
when moving within a partition if there is variation in permissioning.
That of course does not help much to the network admin dealing
with general users who instead must design so that they cannot
move between differently permissioned storage areas unless they
do cross a partition boundary.

Just rest assured that there is at least one person that brings this
issue up in each Windows beta cycle, so perhaps at some point
it will get addressed, even if only because someone gets tired at
hearing the same story over and over