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'");...

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. :)

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--
-----------------------------------

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...

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.