I have written a wrapper script in Perl which will be used on AIX, Linux and Windows and I do not want to change any code for the needs for a specific OS if avoidable.
It works fine so far on all 3 OSes, not blowing up any stacks any more, but I am unsure how to handle writing log files and some other temporary files it needs for some status tracking as it is no demon and will terminate when it's done.
The script will be called by different users and produce the mentioned files. My problem is, that I currently have to give the calling user write permissions to the directory where the logs will be written.
I would like to avoid this and let the logs belong to the user that owns the script so that the calling user will not be able to manipulate any of the files that are written.
su, sudo etc. is no option.
I tried setting setuid-bit, but that didn't help. The created files were still owned by the calling user.
Maybe there is a simpler method to overcome this problem but currently I think about something like trying to change the effective UID for this and see if it helps.
Any ideas or corrections of my thoughts are welcome!
Are all of the users who need to create the log files members of a single group? If so, just change the group for the directory in which the log files will be created to that common group and make the directory writeable by members of that group.
chgrp common_group directory
chmod g+w directory
It isn't clear to me whether you want multiple users to be able to write to log files created by other users or if you just want multiple users to be able to create log files in a single directory. To give all members of the group the ability to update log files created by other members of the group:
Note that the chgrp and chmod commands will both have to be run by the user who owns (created) the file (directory or log file) or by someone with administrative privileges (on many system, that means root).
This wrapper script will be deployed on all hosts in the company, AIX, Linux and Windows. I do not know which technical users (triggered from applications) are going to use it, so I have to assume it will be anybody.
Currently plenty of applications on those hosts execute a client, that does not have the functionalities of the wrapper. This client does not write log files nor is there any mechanisms that need temporary files in it.
For my local tests, everything went fine, even the compiled Perl script on windows.
But then I noticed, that when another user is using the script (AIX/Linux), the directory of the wrapper, where also the logs and temp files are placed, has to be writable for them and the files will have the user and group of the one executing it.
My goal was to achieve, that the files would be written with the uid of the owner of the script, so I thought about trying something with effective uid or something like that.
I will try your suggestions tomorrow at work, thanks so far.
Some systems support set-UID shell scripts; Linux systems do not. So, for a script to be portable to all of the systems you use, a set-UID shell script is not an option.
Ok, that sounds like to have another wrapper that calls the wrapper script with a sudo, as the goal is that the customers don't have to change anything on their side at all when calling the wrapper.
Then there is no sudo on plain windows - I will check if it will run with "runas" but this needs credentials etc.
Thanks so far for your ideas, I will see to what conclusion I come and will let you know.
For the applications running on AIX and Linux it seems it will be a wrapper for the wrapper It will have a sudo call inside so the internal customers do not have to change anything on their side when calling the tool. I did not find a usable way around.
Regarding Windows, I will have to test it first, if the permissions will be problematic.
Thanks again for your input and closing the thread.
It will have a sudo call inside so the internal customers do not have to change anything on their side when calling the tool. I did not find a usable way around.