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

Hi Folks!

I was working on a problem yesterday, in which a cleanup script I was running failed to do it's job, due to permissions. It's called from another script, which backs up files into a tarball, then calls the cleanup script to empty the directory, then untars the tarball in the now empty directory. Now I was running this on a development server, so the script was being run as our dev user, but the directories it needed to clean up (remove and make way for the new backup files) were copied over from production by the prod user. Do you see what I'm getting at?

So the script fails, and I need to find out a way to run the script as a certain user, even though it is being called from another script. I *don't* want to create the script as the prod user, and then chmod it u+s, for obvious security reasons. So has anyone ever encountered this type of problem and got a better solution than the dodgy insecure chmod? And yes, the prod user has a password so I can't do system("su - $user '$second_script'");...

Thanks in advance.

Azatoth a.k.a Captain Whiplash

Make Your Die Messages Full of Wisdom!
Get YOUR PerlMonks Stagename here!
Want to speak like a Londoner?

Replies are listed 'Best First'.
Re: Running Script As Specified User
by busunsl (Vicar) on Jul 04, 2001 at 11:34 UTC
    Have a look at the sudo command.
    IIRC it has an option to execute without password.
Re: Running Script As Specified User
by mattr (Curate) on Jul 04, 2001 at 17:01 UTC
    It doesn't answer your question, but may we assume that
    a) the script which calls your script can't erase those files
    b) you cannot have the script run as root say from cron, or otherwise have a program running as root user to watch that folder for changes.
    c) prod and dev are different user groups, and/or prod does not want to set g+w to the files it moves into there.
    d) you cannot get someone to run a shell script from cron that chowns the files that get moved in there before calling the backup program
    e) your script doesn't have access on prod server that would allow you to grab the files with Net::FTP instead of having prod copy them over himself.
    f) prod is unwilling to maybe upload these things to your script in some fashion.
    I'm sure you've thought of most of these but just want to make sure we are on the same wavelength. :)
Re: Running Script As Specified User
by physi (Friar) on Jul 04, 2001 at 14:53 UTC
    Can't you solve your permission problem, by making the top path owned by your dev-user. Than your dev user should be able to delete all files in his top directory, even if the dev-user is not the owner of the files, but have at least read permission. ?
    ----------------------------------- --the good, the bad and the physi-- -----------------------------------
Re: Running Script As Specified User
by Sinister (Friar) on Jul 04, 2001 at 18:52 UTC
    You might try an ssh connection to localhost, beeing prod user, where localhost holds your publickey...

    Meaning you get something like: system("ssh -f prod@localhost \"chdir dir_to_change_2 && command_to_execute\" ");
    You should never the less make sure the prod user can't access the devel machine from the prod machine, would be kinda sloppy! That's what I would try anyway. Not really perlish, but It might just work...

    Sinister greetings.
    perldoc -q $_
Re: Running Script As Specified User
by MZSanford (Curate) on Jul 04, 2001 at 14:37 UTC

    not that it is any better for security, you could add the dev user to the .rhosts file of the prod userand use rsh ... but, as prod ops, i have to say this is taboo i am sure.

    I have, in the past, used Net::Telnet to log into the local host ... or Net::SSH ... not that either is elegant.

    may the foo be with you
Re: Running Script As Specified User
by thatguy (Parson) on Jul 05, 2001 at 13:08 UTC
    assuming you have root, you could make a new group and put the prod and dev users in it. Then chown -R the directory that has the backup files in it to the new group (making sure it's group write-able)

    Since this is a new group, there should be no other files/dir's on the box that are owned by that group to cause a security issue.

    Also any new files or directories created in the directory you changed will be owed by that new group.

    also not very perlish.. but hey, it works for me on my box.