|
Posted by Roger Abell [MVP] on November 25, 2006, 11:08 am
Please log in for more thread options
> When setting NTFS permissions of a folder in Windows 2000/Windows
> Server 2003 you can choose to propagate the security ACLs to all child
> objects ("Security tab" - "Advanced..." - "Permissions" tab" "Reset
> permissions on all child objects...") - in essence reset all security
> ACLs below a certain point in a directory structure. Works great except
> it could be very nice to be able to ADD or REMOVE individual ACLs below
> a certain point - wishful thinking I guess...
Just to be clear, you are here saying ACLs, whereas you
should be saying ACE(s) at least in the last instance. An
ACL (access control list) is composed of ACEs (access
control entries). Your wishful thinking wants the NTFS
dialog to allow one to state, add this explict ACE at each
inheritance point from here on down. The UI is pretty
complicated for many as it is. I agree with you that one
does at times want to make sure that some new grant is
set everywhere without regard to where in the structure
inheritance is being blocked. For the UI to handle that it
would probably need to allow one to set a hard or else a
conditional inheritance block, i.e. one that would and one
that would not allow later addition of explicit ACEs without
regard to the existance of the inheritance block. The ACL
flags do not at present accommodate that distinction, hence
it is not in the UI (not to mention the further complication
for the UI's users to understand).
What you want to do can be accomplished from script of
NetFx applications.
>
> When COPYING files or folders to a folder within the directory
> structure, the files/folders will inherit the security ACLs from the
> parent folder. Great, no sweat.
>
> BUT! When MOVING files or folders (essentially cut'n'paste using Ctrl+X
> Ctrl+V) the security ACLs of the objects are retained leaving you with
> a set of files/folders with one set of permission in a directory
> stucture with a completely different set of permissions. It works like
> designed, but consider the following scenario:
>
To be correct you need to state that the ACL of the moved object, unlike
when copying, is not reset to the moved-to location _if_and_only_if_
then move is within a single partition. If move to a new partition the
behavior is identical to a copy, with the moved obtaining an ACL that
is solely determined by the moved-to location.
Further, to be correct, you need to notice that when moved within one
single partition, it is only the explict ACEs on the moved object that
are retained. Any ACEs on the moved object that resulted from inheritance
in its moved-from location are (evently) lost and replaced by the ACEs
whose inheritance are appropriate for the moved-to location.
> We have 2 users - User1 and User2.
> User1 have full access to the directories Folder1 and Folder2
> User2 only have full access to the directory Folder1
> If User1 moves contents from Folder2 to Folder1, then there's suddenly
> files/folders within Folder1 that User2 doesn't have access to, because
> they have retained the security ACLs they had in Folder2 - even though
> on the top-level of Folder1 User2 should have full access to all files
> and folders below Folder1.
>
> See the problem?
>
I have bugged this in every beta since W2k beta, agruing that it is now
a meaningless legacy behavior. In NT 4, before the inheritance behaviors
started to be evolved, and when cpu cycles were at a premium, the sematics
of intra-partition move made sense and effected a very real savings (it was
just a write in the table to do the move, effecting the relocation within
that
partition whose organization the table represents).
After inheritance was surfaced to admin control and was further evolved,
the intrapartition move became, IMO, nothing more than an administrative
pain, and in cases a privacy/compliance threat.
> I really miss an option on the folder that will ensure that no matter
> if you copy or move files to a certain directory structure, the
> permissions will ALWAYS be reset to match that of the destination
> directory.
>
For years I have needed to resort to advising that for (intrapartition)
moves, always copy followed by delete of the copied original.
> Is there a hidden feature somewhere that I haven't found yet...? Or
> cannot this be done...? :-/
>
It is not accommodated in W2k3 and prior except by custom code,
either periodic or evented upon filesystem object create.
> (a scheduled reset of permissions using a script is not an valid
> option)
>
> Any thoughts???
>
> Thanks!
> /Nicolaj Rasmussen
>
| 
XML Sitemap