Sam Greenfield wrote:
> At the very least, I believe that there is an interface
> bug in Windows Explorer. When you see the inherit permissions
> checkbox checked, it implies that the permissions of the item are
> identical or stronger than the permissions of the parent item.
> Of course, this is not necessarily the case.

        When you say stronger, do you mean more descriptive? To me, when I
see that an object is inheriting permissions, I would expect the object to
have all the ACEs of its parent (except, of course, those that are set to
apply to "this folder only" on the parent), plus any permissions explicitly
defined on that child object. If the explicitly defined permissions are
allow ACEs, they would potentially allow more access to the file. If they
are deny ACEs, they potentially disallow some access to the file.

> I can certainly see why Russ and others do not feel that
> the behavior we are discussing is a bug. Russ's references to
> the Microsoft support documents were certainly interesting and
> helpful. However, while it is true that inheritance has been
> around since Windows NT 3.1, dynamic inheritance is a new feature
> of Windows 2000.

        I think there is a bug in there somewhere; it's just a question of
where. While the behavior of effective permissions upon moving a file is
unchanged from previous versions of Windows NT (i.e., moving a file results
in it having the same effective permissions/same ACL as it did before), the
evidence of a bug lies in the method in which explorer displays the
permissions on the moved file. If you open the properties of the moved
file, go to security, and go to advanced, and click on the permission in
question, it displays the message "This permission is inherited from the
parent object and controls access to the object....You can edit the
permission only at the parent object where it is defined." This is not the
case. The particular permission is not (or at least need not be) defined on
the parent object; the permissions are not really inherited any longer.
        As Tony Chow mentioned, this is because each file stores a full ACL,
and the only difference between inherited and explicitly defined permissions
is that inherited ACEs are marked as inherited. So, when the file is moved,
the ACL is copied exactly, and the inherited ACEs are still marked as
inherited, even though they no longer are. It seems to me that there would
be two ways to fix the problem. One, when you move an object, you could
"uncheck" the "Allow inheritable permissions from parent to propagate to
this object" box, and change the ACEs on the object which are marked as
inherited to explicitly defined ACEs with the same permissions. This would
result in the permissions behavior for move operations still being the same
as in previous versions of Windows NT. Or, two, the problem could be fixed,
as Ben Cox suggested, by "sweeping and re-flowing" the permissions to the
new object when it is moved, so that it is still set to inherit permissions,
but the previously defined inherited permissions are removed and the
inheritable permissions from the parent are added (and these additions and
removals are propagated to child objects that are set to inherit
permissions). I guess the choice of the preferred solution would be based
on whether you think it is more important to retain a moved object's
effective permissions, as the first method does, or to retain the object's
behavior of inheriting permissions from its parent, as the second one does.

Nathan Yelton

============================================================================
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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]