Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Here is the code:

(root:)

# mkdir /test
# cp /bin/bash /test/sbash
# chmod a+s /test/sbash

(user1:)

$ cd /test
$ ./sbash
$ mkdir trycreate
mkdir: cannot create directory `trycreate': Permission denied

And bash scripts with setuid bit set not work, either.

By the way, my setuid perl script works:

test.pl: (with setuid bit set, owner=root)

#!/usr/bin/perl
mkdir('/test/tryperlcreate') or die 'failed';

execute test.pl by user1 will create the directory owned by root.

share|improve this question

5 Answers 5

up vote 3 down vote accepted

Try exec ./sbash with -p.

sh:~# cp /bin/bash /bin/ape
sh:~# chmod +s /bin/ape
sh:~**$** /bin/ape -p
ape-3.2#
share|improve this answer
1  
The -p option does work, but for shell scripts shebang #!/bin/bash -p doesn't work, while #!/bin/renamed-bash works. I'm wondering how kernel distinguish this, and whether can I configure it to force override to allow it? –  Xiè Jìléi Dec 23 '10 at 1:04

As others have mentioned, this is by design.

Try using sudo rather than setuid scripts.

share|improve this answer

I could repost what's been done to death already, but this is a great read.

Basically setuid shell scripts don't work by default

http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html

share|improve this answer
    
Thanks, I got the point. But what can I do to force enabling the default option? –  Xiè Jìléi Dec 13 '09 at 14:10
    
And, though setuid on bash script is ignored, setuid on the perl ones did work, this really confused me at that time. When I copied /bin/bash to another executable renamed, it doesn't work , too. So, I guess OS ignores setuid on specific shell executables by there file digest, huh?? –  Xiè Jìléi Dec 13 '09 at 14:19
4  
No, it doesn't do it by file digest. It doesn't work for any interpreter. Perl itself is doing it. From 'perldoc perlsec': Perl can emulate the setuid and setgid mechanism when it notices the otherwise useless setuid/gid bits on Perl scripts. It does this via a special executable called suidperl that is automatically invoked for you if it's needed. –  MikeyB Dec 13 '09 at 17:20

This is by design, in Ubuntu as well as in many other modern *nix system. While a setuid is always a potential security vulnerability this is extra so when dealing with shell scripts.

(The classic problem is having someone fool around with what is considered separate arguments by modifying the IFS environment variable.)

share|improve this answer

You cannot make scripts SUID. Fortunately.

You may be interested in the SUID-wrapper program here, though: http://isptools.sourceforge.net/suid-wrap.html

I should also add, please please please make sure that you really need to do this before you do it. SUID binaries can be a great big gaping hole in your system.

share|improve this answer
    
Thank you, I think shc compiler would help, cuz I really don't want to setuid to root, but I have to setuid to some specific user, so, If setuid shell script is dangerout, the OS should give me a warning message rather than silently ignored. Cuz I know what am I going to do and I can sacrifice a bit of security to gain a large convienience. –  Xiè Jìléi Dec 13 '09 at 14:15
1  
The suid wrappers seems not work any more. I'll give up suid script and try something different, thanks –  Xiè Jìléi Dec 14 '09 at 4:36
1  
I think SUDO is a safer alternative to everything else. –  LatinSuD Sep 17 '10 at 11:41
    
You cannot make scripts SUID Actually perl scripts (for instance) allow the SUID. A bunch of `command x` in the perl script resemble a bash script :-) –  ring0 Dec 22 '10 at 17:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.