Re: NTFS Effective Permissions?

From: Gerry Hickman (gerry666uk_at_yahoo.co.uk)
Date: 12/29/04 

Date: Wed, 29 Dec 2004 22:18:42 +0000

Hi,

> For example, I often see NTFS objects whose security settings as displayed
> in the GUI are identical, while a script that uses ADsSecurity.dll to
> display the detailed security settings shows that they are not the same. I
> assume that this has something to do with how permissions were inherited by
> the objects and/or how they were created.

Can you clarify? If you go into the "Advanced" tab of the GUI, are you
saying it's not the same as what you see when using a script? Do you
have any such folder on your computer where you can test this? When you
run CACLS on such a folder, does it agree with the GUI, or with your script?

> If they attempted to superimpose a layer of sensibility on this whole domain
> at the scripting level, I think they would be making the same mistake that
> has been made elsewhere where the nitty gritty details get bound up in a
> presentation layer of sorts.

I know what you mean, but I think the current model does make sense.

> What *would* be nice would be a good
> explanation of just exactly what is meant by by the terminology used at the
> low level, and what it actually does.

I think this is the main problem. Once you start reading the Security
SDK you get to page two, and decide to throw the computer out of the
nearest window, but once you get used to be terminology it gets a lot
easier.

Each "object" (File or Folder if you like) is assigned a "list" (DACL)
of who can access it, and in wot way (read-only, write, execute etc).
Each "entry" in the list is called an ACE (Access Control Entry). Part
of the ACE will be the "Trustee" (e.g. domain\joebloggs). So basically
each file has a collection of ACEs that make up a DACL. You can enum the
entries in script just like any other collection.

In reality, the permissions can be a nightmare even using the GUI. [Ever
looked at multi-level permissions of nested Frontpage webs using
Sharepoint?]. In this case, it's a problem whether you use scripting or
not. The trick is to have a good network-wide strategy for all
permissions that's as simple as possible, but still secure. 

-- 
Gerry Hickman (London UK)

Relevant Pages

  • Re: Possible bug in Exchange GUI (Exchange System Manager.msc)
    ... Connection settings for SMTP server. ... Script that I used for changing settings and reading them ... And GUI ...
    (microsoft.public.exchange.admin)
  • Re: how do you test GUI functionality?
    ... (CART; Classic is the name of the application). ... I have one script which tests handing off control from one GUI to ... # Returns a script to push a specified button in a GUI. ...
    (comp.lang.tcl)
  • Re: GUI v Script
    ... > I maintain an old system which has a locally developed script interface. ... > faster with a CLI than a GUI, particularly if the GUI is like Windows, ... with both programming skills and subject matter knowledge. ...
    (comp.object)
  • Possible bug in Exchange GUI (Exchange System Manager.msc)
    ... I’m writing this because I think I found one small bug in Exchange GUI. ... Connection settings for SMTP server. ... Manager.msc on first server and iis.msc on second server. ... First I used script to target settings for SmtpSvc/1 ...
    (microsoft.public.exchange.admin)
  • Re: Scalars Leaked and Segmentation Fault
    ... where you can launch threads after a gui was created. ... before you create the main part of your script. ... (and possibly refs). ... but are harmless. ...
    (comp.lang.perl.misc)