Re: Want to turn permission propagation off in SetNamedSecurityInfo . . .
From: Toby Everett (toby_at_ovod-everett.org)
Date: 02/03/04
- Next message: pete_reay: "Re: Suppressing user prompt for client certificates"
- Previous message: Michel Gallant: "Re: XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1"
- In reply to: Dave McPherson [MSFT]: "Re: Want to turn permission propagation off in SetNamedSecurityInfo . . ."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 2 Feb 2004 23:04:01 -0800
"Dave McPherson [MSFT]" <dave@n0Spm.m1cr0s0ft.c0m> wrote in message news:<401ee827$1@news.microsoft.com>...
> The low-level access control API can set the protected flag w/o causing
> propagation. This limits your exposure vs. using low-level api to modify the
> ACL (which is sounds like you may be doing.) Though generally using
> low-level access control APIs is not recommended.
The ACL and ACEs were pretty easy to parse, especially since all the
structs are published. The object-specific ACEs are a bit weird and I
haven't written the code to parse them yet, but it's still easy to
parse the ACL since the size of the ACE is part of the struct. I
think it's infinitely easier to parse them and manipulate them in Perl
than it is to struggle with the C APIs.
Far more difficult, and it required a lot of reverse-engineering, was
determining the exact algorithms used to propagate the permissions. I
didn't do this in order to set permissions (no need -
SetNamedObjectSecurity is infinitely faster than my code would ever
be), but because it's the only way to detect when moved files have
resulted in mis-inherited permissions. Moving files doesn't cause
inherited permissions to be recalculated, but since the INHERITED_ACE
bit is set, if you can calculate the permissions the node should have
inherited from the parent, you can determine if the permissions are
properly inherited. If they're misset, a quick call to
SetNamedObjectSecurity will correct them.
In the end, I have a blazingly fast library precisely because it's
easy to code things efficiently in Perl. For instance, I cache all
calls to LookupAccountName (it can be a very expensive call). File
systems generally don't have millions of DACLs or ACEs - they have
hundreds or thousands - and so I cache every ACL and ACE I see, as
well as all of the parsed and computed information. I used mutable
flyweight objects to get the illusion of mutable objects while
maintaining a central cache indexed on the binary forms for the ACEs
and ACLs.
The end result is that on a P4 1.8 GHz, if I'm working from a cached
FS (i.e. the second time I scan the entire drive), I can scan around
500 files per second for permissions and dump out all explicit
permissions, all mis-inherited permissions, etc. It's a really easy
environment to work in.
As in:
my $namedobject = Win32::Security::NamedObject::SE_FILE_OBJECT->new($filename);
my $dacl = $namedobject->dacl();
$dacl->deleteAces(sub {lc($_->trustee()) eq lc($trustee) &&
!$_->aceFlags->{INHERITED_ACE});
$namedobject->dacl($dacl);
That opened $filename as a Win32::Security::NamedObject of
SE_FILE_OBJECT, read the dacl, then deleted any ACEs from the DACL
that had a trustee that matched $trustee and that didn't have the
INHERITED_ACE bit set (using an anonymous subroutine as a filter to
select which ACEs to delete), then wrote the DACL back to the object.
There's also a infrastructure designed for writing recursors (well,
queue faked recursors:) to scan trees of nodes.
--Toby Ovod-Everett
- Next message: pete_reay: "Re: Suppressing user prompt for client certificates"
- Previous message: Michel Gallant: "Re: XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1"
- In reply to: Dave McPherson [MSFT]: "Re: Want to turn permission propagation off in SetNamedSecurityInfo . . ."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|