suid - am I missing something or does this not work?

[vincentv]

Hi

My understanding of suid, when applied to an executable file, is that when it is run, the file runs with the permissions of the file owner, not the user that runs the file.

 

I've tested it with this simple shell script:

 

#!/bin/bash

#list root's directory

 

echo I am $(whoami)

ls /root

 

 

the script is in /usr/local/bin and owned by root, is executable by all and does not have suid

 

If I run it as root I get

 

I am root

bin

core.10216

core.7580

core.7598

crossover tips

Desktop

drakx

ffjuser40ce

grepresults

icon.ico

javaws.png

MDRepository.log

mimeinstall.results

ooo_setup_english.pdf

Openoffice

PC and System Info

plugininstall.results

registry

results

testprintfile.sxw

tmp

vpd.properties

wacom_drv_old.o

wacom_old.o

 

as you would expect

 

 

if I run it as me I get

 

I am vincent

ls: /root: Permission denied

 

as expected

 

If I now set the script's permissions to Set UID, I would expect to get the same output when I run it as me , as when I run it as root. But nothing changes!

 

Incidentally, how do you capture screen output in a terminal? It doen't let you copy it so I had to resort to redirecting the output to a file.

 

Thanks

 

Vince

[tyme]

SUID doesn't work that way. If you are a regular user you can't start something as root without entering in roots password, as in su/sudo

 

however, if you give the script the UID of your regular user account and then run it as root, it should give you the same reply as if you ran the script as the regular user.

 

i could be wrong, but i believe that's how it should work...

[vincentv]

Thanks for the reply tyme, I did a bit of experimenting by changing the script's owner but the User Id was never set to the owner - no matter who the owner or who ran it.

 

After re-reading the man and info pages followed by some more searching on the net, I think I have found that I am half right - if SUID is set then the file will run with the permissions of the owner, not the user. This allows root, for example, to allow controlled access to areas of the system not normally accessable to normal users - for changing passwords for example. A search for files with SUID bits set

 

find / -perm +4000 -user root -type f -print

 

showed that there were many such files. However they were all binary executables, not scripts of any description. So perhaps that is the answer: suid and guid only apply to binary executable files - well its the best I can come up with. It seams a shame really, as 'suid' ing scripts would be really useful.

[aru]

It seams a shame really, as 'suid' ing scripts would be really useful.

Mainly for crackers :lol:

 

The fact is (at least AFAIK) that the linux kernel doesn't execute scripts (versus binaries), it lauches the interpreter (which is not suid/guid), then interpreter (ie bash) runs the script.

 

In other words, suid scripts are nonsense because under the kernel eyes, a script is just a parameter of the interpreter who is running it.

 

(that's true in GNU/Linux, I don't know other UNIXes)

[vincentv]

That makes perfect sense aru. In fact, if that is how it works, then suid would pose a major security breach since all scripts would acquire root privilages! The task of maintaining script security would then fall on on the interpreter - which is not a good thing since fragmentating security tasks would lead to inconsistancies across the operating system and be difficult to maintain - the whole point of a modular, object oriented system is to avoid this by providing a single 'expert' to handle a commonly used task.

 

Vince