joeware - never stop exploring... :)

Information about joeware mixed with wild and crazy opinions...

Argh, Perl let me down… Well at least one of the Win32 modules did…

by @ 5:33 pm on 5/20/2007. Filed under tech

I love perl, absolutely adore it. I love how I can take one small exe and one small DLL and take it anywhere and get just buttloads of functionality out of the core language. Well I needed a script to tear through and document ACLs on a file system. Now I didn’t expect the core perl functionality to handle this but figured one of the modules that come with it would do the trick… sure enough, it looks like Win32::FileSecurity will do what I need. Simple example…

Aww crap, it can’t get the Security Descriptor on a file that is opened by someone else… WTF… Not only that but the module blows you right out of the script, no chance of capturing the error… I look closer at the docs and sure enough down in Known Issues / Bugs – “Errors croak, don’t return via $! as documented.”. WTF people. If you write a module you should NEVER die or croak from out of that module… Return to the script and let it decide what it wants to do. What could have and should have been a nice simple task is now going to be a bit of a pain.

So I look at CACLS and XCACLS and seriously, they are pretty poor especially if you are trying to parse the info in a script. This means I am now stripping the Security Descriptor code out of AdFind so it can be standalone and added the one line needed to get the SD from a file/directory instead of from AD. Then add a couple of printf’s[1] to write the output the way I would like it for scripting…  

I have had this on the list of things to write for a long time, so good to be getting it done now. I am trying to make it as flexible as possible so I can use it for any ACL type, not just files/folders. Far handier that way.

   joe

 

[1] Well not really but that is the basic idea, I am actually using ConOut’s and ConOutNL’s but those are my special output functions.

Rating 3.00 out of 5

6 Responses to “Argh, Perl let me down… Well at least one of the Win32 modules did…”

  1. flachance says:

    Joe, do you intend to make this tool freely available to those poor souls who can’t write code? I could use such a tool.

    Thanks so much for the great tools you have made freely available.

  2. Evan says:

    Have you looked at SetACL (http://setacl.sourceforge.net/)? The reporting capabilities there might do what you need. I feel like it’s got an odd command-line syntax (gives me a feeling a little like the argument syntax for “dd” does as compared to other *nix utilities), but it’s been very valuable. I use it in user home directory / roaming profile provisioning scripts, and when I’m auditing server configurations.

  3. Carlos Veira says:

    SetACL is a fantastic choice. Anyway, if you happen to need or want to review some more options, you can try SUBINACL (Windows Resource Kit) or the new ICACLS tool shipped with Vista.

  4. Scotte says:

    I really like SetACL’s ability to set perms on other objects besides files, but for doing file perms, I prefer FileACL (http://www.gbordier.com/gbtools/fileacl.htm). And yeah, the syntax is MUCH less awkward than SetACL.

  5. Carlos Veira says:

    Joe, I forgot to mention the Set-Acl/Get-Acl CmdLets that you can find inside PowerShell may also be useful.

    Maybe PowerShell Enviroment could be a nice envirionment for your purporses …

  6. Shannon says:

    I wrote a small script that uses setacl to document and allow searching on acls using setacl.exe.

    @4 I tried fileacl for the same purpose because setacl does have a very odd syntax imo. I found that setacl was much, much faster than fileacl (in my instance). I haven’t found another tool out there, including all of the various ones that MS provides that rips through acls near as fast as setacl.

    I’ve recently been looking at powershell’s get-acl to see if there is any potential for it, but nothing to report there yet.

[joeware – never stop exploring… :) is proudly powered by WordPress.]