in reply to Re: perl script to copy files as admin
in thread perl script to copy files as admin

Thank you for the replies, I'm using Windows environment: Actually I used to do this manually using admin ID, here users will not get any access. So my intention is to create a script which will be run by user to do so. I wanted to know is there any scope to use encripted password or compile the script in perl, here is something like: 

use File::Copy;

$filetobecopied = "<dir1>\*.*"

$destcopy = "<dir2>";

copy($filetobecopied, $destcopy) or die "File cannot be copied.";

[download]
Is ther any scope to user admin id and password? As user can not do any thing else except copying files with this compiled script. Any idea is greatly appreciated.

Replies are listed 'Best First'.
Re^3: perl script to copy files as admin
by afoken (Chancellor) on Jul 23, 2009 at 19:26 UTC

    The copy function of File::Copy can copy only a single file at a time, and it has to be called with a destination file name, not a directory. You could have learned that from the File::Copy documentation.

    If you want to copy more than one file, you need a loop. If you want to copy an entire subtree, you need to recurse into source and destination directories. File::Copy::Recursive can do both, if you RTFM.

    Regarding your privileges problem, you need to start your copy script as a privileged user. Windows has the runas command, and it offers the services infrastructure for a clean separation of a unprivileged user interface and a privileged background service. runas needs the Administrator password at runtime (and you don't want to give it away!), the service way doesn't. Remember that privileges require responsability, so use strict, use warnings, and enable the taint mode (#!perl -T). Verify all input and refuse to work when the input does not match the rules. Using a web server could be a simple workaround, for read accesss to the "restricted location", any web server could do the job, for write access, a WebDAV enabled webserver could do the trick. No need to invent new protocols. Of course, you also could use a file upload form and a CGI for write access.

    Privilege separation can be a real pain under Windows, there are several attempts to clone the common su or sudo utilities, starting with a single batch file and ending with a huge services infrastructure. I still haven't seen any Windows utility as reliable and secure as sudo on Unix.

    Think about your initial problem, or better: Explain it to us. Why do you think you need to to copy files from a restricted location using admin id and encrypted password? If the "restricted location" is the source, just make it world readable, but writeable only for the Administrator account. This can be done using standard Windows access controls. If the "restricted location" is the destination, you are defeating your restrictions, so just drop them and make it world (or group) writeable.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
      Thank you Alexander, Your tips are really helping me. Actually my intention is to do a particular work (like copy, move etc)using a previleged ID and encrypted password and then exit. I understand that web access and giving read permission can serve the purpose, but we don't want to access those stuffs except particular user. Is there any perl module or utility (like File::Copy::Vigilant can varify something) is able to validate user previlege or scope to run as different user? Thanks again for your input.
[reply]
        Actually my intention is to do a particular work (like copy, move etc)using a previleged ID and encrypted password and then exit.

        You need a tool equivalent to sudo. Search the WWW for "sudo for windows", "surun", "machmichadmin" (from the german c't magazine), "makemeadmin", or "sudown" and use one of those tools.

        I understand that web access and giving read permission can serve the purpose, but we don't want to access those stuffs except particular user.

        I don't understand what you mean (Parser error near "except particular user"). If you want to grant one or more users access privileges to the "restricted location", a web server can easily do that, using Basic or Digest HTTP Authentication, and on Windows, you can also use NTLM authentication.

        Is there any perl module or utility (like File::Copy::Vigilant can varify something) is able to validate user previlege or scope to run as different user?

        No. Privilege checks, user authentication, and user switching are jobs of the operating system, not of an application. Applications can not do this. (Actually, there are ways to DROP privileges inside an application, and to start a different program under a different account. The most privileged account, typically root / LocalSystem, can also switch to a completely different account, but not back.)

        File::Copy::Vigilant is a completely different thing: It verifies that a file is copied (or moved) exactly from source to destination. No privileges and no user switching involved.

        Web servers often have their very own user and group management, completely separated from the underlying operating system. But for the operating system, the web server operates under a single user account, typically an unprivileged one. A second, privileged account is used to bind() to privileged ports and/or to run helper programs under different O/S accounts, but this is completely optional.

        You can use the web server approach to run programs using the privileged account, with a few minor restrictions: The web server must run using the privileged account, and the programs must not attempt to use any GUI features: No windows, no alert box, no interaction with the desktop -- simply because there is no such thing as a desktop or a GUI for background services, neither on Windows nor on Unix derivates.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom