bowei_99 has asked for the wisdom of the Perl Monks concerning the following question:

Update: I realized I posted something a while back, and realized why I looked at setacl in the first place - that Win32::Perms wasn't getting the local groups associated with the share, only the groups on the domain. I tried it again, and confirmed that's still the case. I tried the rmtshare solution that was suggested, but that doesn't really work in my Active Directory environment. (rmtshare is part of the Win NT 4 Resource Kit, and was not in the Win2k Resource Kit). Anybody seen this, where it doesn't recognize local permissions?

Update 2: The same thing happens when querying two network shares, one a Win2k server and another a netapp box, but it does get the local groups if I query the box that the script is running on. Odd... I emailed bugs@roth.net, since there doesn't seem to be any sort of discussion board on their site to pose this question.


Hi, I'm writing code to manage NTFS permissions. I looked at Win32::Perms, and may use that, but also found an application, setacl, that offers functionality through an ActiveX control (OCX), which can be used from any COM-enabled language. The author includes a sample perl script with the download, from which I've excerpted code below. Are there any advantages to using that vs. Win32::Perms? I contacted the author, and he's not really developing it anymore, and my gut feeling is that it isn't as well tested as Win32::Perms. But I wanted to post this question, since there may be issues that I'm not aware of. (I'm more a unix person, so I don't know all too well how perl works as 'COM-Enabled' language, among other things).
use strict; use Win32::OLE qw(in with EVENTS); use Win32::OLE::Const; # # Start of script # # Create the SetACL object my $oSetACL = Win32::OLE->CreateObject ('SetACL.SetA +CLCtrl.1') or die "SetACL.ocx is not registered on your system! Use r +egsvr32.exe to register the control.\n"; # Load the constants from the type library my $const = Win32::OLE::Const->Load ($oSetACL) or di +e "Constants could not be loaded from the SetACL type library!\n"; # Enable event processing Win32::OLE->WithEvents ($oSetACL, \&EventHandler); # # Check arguments # my $Path = $ARGV[0] or die "Please specify the ( +file system) path to use as first parameter!\n"; my $Trustee = $ARGV[1] or die "Please specify the tr +ustee (user/group) to use as second parameter!\n"; my $Permission = $ARGV[2] or die "Please specify the per +mission to set as third parameter!\n"; ... # Set the object my $RetCode = $oSetACL->SetObject ($Path, $const->{S +E_FILE_OBJECT});

-- Burvil

Replies are listed 'Best First'.
Re: Why use OCX on Win32?
by GrandFather (Saint) on Apr 04, 2006 at 00:06 UTC

    ActiveX is really designed to provide a way for languages like VisualBasic to get access to goodies. It's rather cumbersome compared to a "native" solution like Win32::Perms which hooks straight into the Windows API. Both should work but Win32::Perms ought be a lot faster with fewer dependencies.


    DWIM is Perl's answer to Gödel
Re: Why use OCX on Win32?
by displeaser (Hermit) on Apr 04, 2006 at 15:43 UTC
    Hi,

    something you havnt mentioned and may already have discounted is write a perl wrapper around the cacls or xcacls command(s) (instead of using Win32::Perms). It's (cacls) comes with every nt system from nt4 up (and maybe previous ones to).

    Hope this helps.
    Displeaser
      I tried that, too. I get this when I try it on a share:

      H:\working_files\win32>xcacls G:\IG-S G:\IG-S <Account Domain not found>(OI)(CI)C BUILTIN\Administrators:(OI)(CI)F DOMAIN1\Domain Admins:(OI)(CI)F AD-DOMAIN\LabOps Admins:(OI)(CI)F NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Users:(CI)R
      So I did a google search, and found this link and this link, in addition to this link at the Microsoft knowledgebase, which seem to point to the unreliability of xcalcs. Although the knowledgebase article says it's only for NT 4, we're running Win2k, with all the needed patches.

      So maybe it's something wrong with the OS itself ...

      -- Burvil