One way you can do this... ( and this is not a secure way at all ) is write a script that moves the file... Owner of the script should be the owner of the directory in which the file should be copied. and give the script 4755 permissions. This will make it executable by everybody and anybody who runs the script will execute it AS the owner of the script.
Now, I've been reading security books and they suggest against it.. PLUS if you decide to do this. DO NOT write a shell script, use PERL or C(++) instead. it will make it more secure.
Maybe you can have people place the files in the world writable dir and then have cron execute your script that moves files from that dir into whichever one you need. That way you don't run the risk of giving users too much access.
SUID is an option... but not a secure one ( if you are concerned with security )
You could also give the user restricted access to SAM and create an icon within SAM that runs the script. Make sure the "Execute using root's id" is selected (or a user who has access to the protected directory). The user double clicks on the icon (assuming xwindows) and the script will run as root or it run as the user having access to the directory. The script can also run from a terminal. However, I don't know what the security implications are.
My bad 4755 will set "setuid" not a sticky bit
After 4755
The script permissions would look like:
-rwsr-x--- 1 root somegroup 1234 Feb 13 13:15 script_name
Then you modify /etc/group so that the user is a member of the group somegroup
somegroup::123:userid
The problem with this is that if there are multiple people that are a member of somegroup then ALL of them can run the script as a root.
Use of sticky bit
1) on a file: helps keeps portions of the program in memory to make it faster to run again.
2) on a directory: you must own the file in the directory in order to delete/move etc.. it.
And you see the sticky bit when an ls -l shows a "t" in the last position.
lets say you have a script that you want people to execute. The script will perform some actions on the system that regular user does not have permissions to... when you set permission to the script and you give it a '4' before the perms it will set an SUID which means that whoever will execute the script it will always run as the owner of the script. best command to look at as an example is a 'passwd' command on UNIX. when you change your own passwd it modifies /etc/passwd ( if you're not on a trusted system ). Now you as a regular use can't modify /etc/passwd.. you can only read it.. how does this work ? 'passwd' is owned by root. and has a SUID set.. which means when you run it to modify the passwd it is actually ran as root and therefore has enough previliges to modify /etc/passwd.
Getting back to your original request.
if you decide to use SUID,
#!/usr/bin/ksh
SECURE_DIR="/path/to/secure/dir"
if [ "$#" -ne 1 ]
then
echo "Must move one file at a time\n"
exit 1
else
FILE_TO_MOVE=$1
fi
if [ ! -f "$FILE_TO_MOVE" ]
then
echo "$FILE_TO_MOVE does not exists.. check path and try again\n"
exit 1
else
/usr/bin/mv $FILE_TO_MOVE $SECURE_DIR
MOVE_STATUS=$?
if [ "$MOVE_STATUS" -ne 0 ]
then
echo "Move was not successful\n"
else
echo "Successfuly moved the $FILE_TO_MOVE to $SECURE_DIR\n"
fi
fi
==================================================
as you can see.. this is the most basic version of the move script which will run a couple of checks. 1. Make sure one argument is supplied when the script is ran. 2. Make sure the file exists before we try to move it. 3. make sure the 'mv' command didn't produce any errors. this is just an example.. you might wonna write your own and make sure that it works and does all the proper checks.
Now, as I have posted on my first reply.. SHELL SCRIPTS ARE NOT SECURE. any bad user who knows enough about scripts and shells, can make some damage, but I don't know your environment and maybe you're not too concerned with security...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.