setuid

[Mike_21]

Situation: I have a script in the /root directory permissions are rwx for "root only".

I would like to give user x the ability to run this script as root, I know this is possible. I tried to chmod u+s script, it now looks like rws.

This did not work........ DO I have to move this script out of /root?

Thanks

[Patrick Wallek]

If you want the script to run as root, but you want the other user to have access to it, you can do a couple of things.

1) Change the permissions of the script so that it has group execute permission and then change the group to one that the user is a member of. Then when the user runs the script, it will run as root.

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.

2) You could download and install the product sudo http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/sudo-1.6.2b1/

Then you can set up that user in sudo so that he has acccess to that script and no one else does. This allows you to leave the permissions of the script set to 700 or 500 and root as the owner.

I would personally vote for using sudo. It allows you to do a lot of things with assigning 'root' privileges to users without them actually having to know the root passwd. Once sudo is set up, you run a command by doing:

$ sudo command_name

It then prompts the user for their password, if you set it as such, and the command then executes.

[Krishna Prasad]

You could also use restricted SAM.

You would need to add you script as a custom application.

Then you run sam -r and setup the user(s) you want have acess to this script or any SAM functions.

The downside to this is that the users have to run SAM to run the script.

[Kelli Ward]

Hi,
You safest bet, to prevent tampering, may be to chmod 555 <script>. This will give you:
-r-xr-xr-x permissions on the file and prevent anyone from inadvertantly overwriting the script or damaging it. Even a well intentioned root user won't be able to write to it without "forcing" the change.
Good luck,
Kel

[Kelli Ward]

Ooo... That reminds me. You can also use your file manager to edit the permissions.
Find the file in your file folder, right click on it, then right click on properties. There will be permission buttons you can click to set the permissions however you wish.
One: you must be owner to do so.
Two: You must be running a graphical interface to do this. I.e: CDE or HP-Vue
Good luck again,
Kel

[Darrell Allen]

Hi all,

Just a word of caution. Don't set perms to 4555 unless you want everyone to be able to run the script as root.

Darrell

[Mike_21]

The response that Patrick gave will not work and gives an error message... Permission denied.

[Darrell Allen]

Hi Mike,

I've used Patrick's suggestion a number of times. Something must be just a little off.

-rwsr-x--- root somegroup ... script_name

That should work in 11.x IF the user is in somegroup (as specified in /etc/group) or somegroup is the users primary group (as specified in /etc/passwd).

If running pre-11.x then you need /etc/logingroup. Simply create a symlink pointing to /etc/group:
ln -s /etc/group /etc/logingroup

Darrell

[Darrell Allen]

Dang, it helps to read the question. /root doesn't have permissions for the user. You either have to open that up or put the script in another directory that the user has r-w perms.

All things considered, sudo and restricted SAM are better choices.

My apologies for not reading better. Couldn't see the forrest for the trees.

Darrell

[Patrick Wallek]

What are the permissions on the /root directory, the file you are wanting to execute and what is the output of 'id username' where username is the id of the user that you want to execute this script?

[Kelli Ward]

Whoops, I didn't exactly read the post right myself.
Quick question, This script, does it run internal commands that require root access to use them? I.e: reboot and date
If not, you may be able to create a copy, owned by the user in their directory. If they do, you may need to give them permission to run the internal "root" commands as well. If, I am now understanding your question correctly.
Best of luck to you,
Kel

[Helen French]

Hi Mike,

If I understood correctly, then you can use the ACL commands for giving access of a specific file for a specific user.

For eg: user1 needs execute permission for a file called /script1, then

# chacl 'user1.%=rx' /script1

HTH,
Shiju

[Mike_21]

Sorry about the confusion....

I better add that this scripot that is located in /home/root accesses directories owned by root. So when userx executes this script, I would think that userx doesn't get roots permissions, thus is why it is failing. I would definitely prefer sudo access, however, the current situation will not allow this (long story). Also userx is running a restricted shell.

Thanks for the help...

[Krishna Prasad]

I would try SAM if this is a big if it works with a user you is using restricted SAM?

[Ruediger Noack]

It is NOT possible to set the s-bit to a shell script, only for executables.
Make a little c program with
system(script)
in it and set your s-bit to the compiled program.

Ruediger

[James R. Ferguson]

Hi Mike:

If this is *really* what you want to do, and I'm sure you know the reasons for avoiding 'setuid' and 'setgid' scripts and programs, so I won't lecture, then:

1) Use a Posix script (#!usr/bin/sh)
2) Make the *owner* of the script 'root'
3) chmod the script 4555

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Mike:

...and I should add that the directory in which the script or executable resides is immaterial. Put it whereever you want/need users to get it. To a very limited extent, this can help protect it, although these are very dangerous little animals to have.

Regards!

...JRF...

[Wodisch]

No Mike,

sorry to interfere with the "olympian" (not too sorry, though ;-), but it is NOT a good idea to give a setuid script world read permission, simply execute permission for those to start it, and read permission for the owner is enough.
Even though a setuid script should NOT have any holes in, it is still not advisible to let everybody see how to tamper with it :-(

They should not even *know* it is a script...

Hence for dircteory "/root" and the file "/root/dangerus" you could set the permissions as follows:
-r-s--x--- 1 root mighty ... /root/dangerous
-r-xr-xr-- 1 root mighty ... /root

where the user would have to be member of group "mighty" (do you have the sym-link "/etc/logingroup->/etc/group"???)

Just my $0.2,
Wodisch

[Patrick Wallek]

Sorry Woodisch, but JRF is correct in his assesment of permissions. A shell script can NOT be executed with having 'read' permission set.

Here's an example. I created a script called test_script. It's contents are:

#!/usr/bin/sh
echo "This is a test on `date`"

Now I set its permissions to 711 (owner is root, group is sys) and tried executing it as a regular user.

$ ll test_script
-rwx--x--x 1 root sys 46 Feb 14 14:27 test_script
$ ./test_script
/usr/bin/sh: ./test_script: cannot open

But when I change the permissions to 715:

$ ll ./test_script
-rwx--xr-x 1 root sys 46 Feb 14 14:27 ./test_script
$ ./test_script
This is a test on Thu, Feb 14, 2002 02:28:31 PM


So you can not have a shell script with ONLY execute permission. It won't work. The read permissions allows your shell to "read", or parse and run, the script. The execute permission allos you to do a ./scriptname to execute so you don't have to run the script by doing 'sh scriptname'.

You can get away with having execute permission only on a compiled program because it is already compiled and the shell doesn't have to read it.

Sorry to burst your bubble.

[James R. Ferguson]

Hi Wodisch:

I wholly agree. Read permissions are unnecessary. The less known and shown the better. Thanks!

Regards!

...JRF...

[Patrick Wallek]

You do have a point about the set-uid script though Woodisch. Sorry I didn't take my test one step further initially.

The set-uid script can run with permissions of 4511.

$ ll test_script
-r-s--x--x 1 root sys 46 Feb 14 14:27 test_script
$ ./test_script
This is a test on Thu, Feb 14, 2002 02:37:38 PM


So the permissions just depend on how you want to execute it.

[Darrell Allen]

Mike, have we confused you yet?

Another word about suid and read permissions on a script that may help clear up the issue...

If the suid script does not begin with #!/usr/bin/sh (or whatever), you cannot run it without read permissions. If the first line is #!... then the suid script can be executed without read perms.

So using Patrick's example:

$ ll test_script -r-s--x--x 1 root sys 46 Feb 14 14:27 test_script
$ ./test_script
This is a test on Thu, Feb 14, 2002 02:37:38 PM

This will work if test_script's first line is
#!/usr/bin/sh
or any other appropriate shell.

The script will not work if the first line does not specify the shell UNLESS you add read permissions for other (assuming the user is not a member of group sys).

It's always a good idea to put specify the shell as the first line of the script, especially for suid scripts.

Darrell

[Wodisch]

Hello again, Mike!

to clarify a little bit:

1) ten professionals = twelve opinions ;-)

2) to execute a program the user trying to do this needs only the "x" permission
3) if the program is "SUID", then the code is executed by the OWNER of the programfile
4) if it is a script then taht OWNER needs read permission, but not the STARTER

Kind regards,
Wodisch

[Steven Sim Kok Leong]

Hi,

This is indeed a very enjoyable thread. :-)

As mentioned by the rest earlier, the easiest way to your problem is to configure restricted SAM for your users to run those restricted scripts with superuser privileges. Your user will just need to run:

$ /usr/sbin/sam

In this case, you do not even need to use the setuid bit and risk having a potentially vulnerable script/program being compromised by a buffer overflow security exploit.

It is a security best practice to minimise the number of setuid/setgid programs in your system to reduce your exposure to such vulnerabilities. In fact, many security vulnerabilities were caused by the setuid/setgid bit being turned on and more often than not, security advisories encourage disabling these bits.

If you use restricted sam, your script can have the following permissions:

-r-x------

Adopt the principle of least privileges, minimise the number of setuid/setgid programs on your system and reduce thus, reduce the risk of a vulnerable setuid/setgid program/script being exploited.

Hope this helps. Regards.

Steven Sim Kok Leong

[Ruediger Noack]

Hi pros,

all the discussion makes me very confuse because of s-bit and shell script
I think all what Mike want to get is a shell script to execute for any user but with root permissions for executing.
Example: start dmesg
Any user who start this get the error message:
Can't read kernel menmory
Ok so far.
Now I write a script dmesg.sh with ohne one raw in it:
/usr/sbin/dmesg

The permissions:
-r-sr-xr-x 1 root sys 16 Feb 15 09:13 dmesg.sh

If i execute the script as any use I get the same message: Can't read kernel memory

If the exexutable from this little c program

main()
{
system("/usr/sbin/dmesg");
}

get the same permissions any user get the root permissions for this program. The output of the program is the full dmesg output.

In my opinion the s-bit in a shell script has no effect, only for executables.
Am I wrong?

Ruediger