Re: how to make an executable run as another user

2004-09-18 Thread Richard Bradley
I understand now. Thanks very much for all your help. 

Rich


On Saturday 18 September 2004 11:31 am, Matthew Seaman wrote:
> On Fri, Sep 17, 2004 at 04:53:31PM -0400, mailing lists at MacTutor wrote:
> > QUOTE: "In most UNIX kernels there exists what is called a 'race
> > condition' when executing scripts. Scripts are pieces of code which are
> > interpreted by, strangely enough, interpreters. Common examples of
> > interpreters are perl, sed, and awk. So when you have in your perl code
> > #!/usr/local/bin/perl it tells the operating system to start executing
> > the perl interpreter with the current script as input. Between the time
> > that the perl interpreter starts executing and the time that it reads
> > in your script the 'race condition' exists. At this time, a mischievous
> > person could 'win the race' and be able to replace your script with
> > another. And if your script is running as setuid, that person's script
> > would run as your user! So their script could do anything that you
> > could do from the command line. As a result, most UNIX kernels will
> > disable users from running scripts as setuid. The most common way
> > around this is to create a wrapper program around your script. A
> > wrapper, in this context, is a small program, possibly written in C,
> > that when executed will simply run your script. The 'race condition'
> > does not exist for real executables and so you won't be thwarted by the
> > kernel itself."
>
> Actually, this should no longer be a problem in any up to date version
> of Unix.  The race condition between the kernel reading the script to
> find what interpreter to invoke, and the interpreter then to read and
> interpret the script was solved by having the kernel pass an open
> filedescriptor on the script file to the interpreter.  One way of
> testing if your OS supports this is the presence of 'file descriptor'
> devices under /dev -- eg. under FreeBSD you get:
>
> happy-idiot-talk:/usr/local/etc:% ls -la /dev/fd/*
> crw-rw-rw-  1 root  wheel   22,   0 Jul  5 17:08 /dev/fd/0
> crw-rw-rw-  1 root  wheel   22,   1 Jul  5 17:08 /dev/fd/1
> crw-rw-rw-  1 root  wheel   22,   2 Jul  5 17:08 /dev/fd/2
> crw-rw-rw-  1 root  wheel   22,   3 Jul  5 17:08 /dev/fd/3
> crw-rw-rw-  1 root  wheel   22,   4 Jul  5 17:08 /dev/fd/4
> crw-rw-rw-  1 root  wheel   22,   5 Jul  5 17:08 /dev/fd/5
> crw-rw-rw-  1 root  wheel   22,   6 Jul  5 17:08 /dev/fd/6
> crw-rw-rw-  1 root  wheel   22,   7 Jul  5 17:08 /dev/fd/7
> crw-rw-rw-  1 root  wheel   22,   8 Jul  5 17:08 /dev/fd/8
> crw-rw-rw-  1 root  wheel   22,   9 Jul  5 17:08 /dev/fd/9
> [...]
>
> However, the horror has been so beaten into the collective unconscious
> inherited from earlier days of Unix that shell scripts are still
> automatically stripped of any setuid or setgid bits by default on most
> Unix variants.  I did see a setuid 'lp' script as a standard part of
> the lp system on a Solaris 8 box once -- took me a long time to
> convince myself it was actually safe.
>
>   Cheers,
>
>   Matthew

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: how to make an executable run as another user

2004-09-18 Thread Matthew Seaman
On Fri, Sep 17, 2004 at 04:53:31PM -0400, mailing lists at MacTutor wrote:

> QUOTE: "In most UNIX kernels there exists what is called a 'race  
> condition' when executing scripts. Scripts are pieces of code which are  
> interpreted by, strangely enough, interpreters. Common examples of  
> interpreters are perl, sed, and awk. So when you have in your perl code  
> #!/usr/local/bin/perl it tells the operating system to start executing  
> the perl interpreter with the current script as input. Between the time  
> that the perl interpreter starts executing and the time that it reads  
> in your script the 'race condition' exists. At this time, a mischievous  
> person could 'win the race' and be able to replace your script with  
> another. And if your script is running as setuid, that person's script  
> would run as your user! So their script could do anything that you  
> could do from the command line. As a result, most UNIX kernels will  
> disable users from running scripts as setuid. The most common way  
> around this is to create a wrapper program around your script. A  
> wrapper, in this context, is a small program, possibly written in C,  
> that when executed will simply run your script. The 'race condition'  
> does not exist for real executables and so you won't be thwarted by the  
> kernel itself."

Actually, this should no longer be a problem in any up to date version
of Unix.  The race condition between the kernel reading the script to
find what interpreter to invoke, and the interpreter then to read and
interpret the script was solved by having the kernel pass an open
filedescriptor on the script file to the interpreter.  One way of
testing if your OS supports this is the presence of 'file descriptor'
devices under /dev -- eg. under FreeBSD you get:

happy-idiot-talk:/usr/local/etc:% ls -la /dev/fd/*
crw-rw-rw-  1 root  wheel   22,   0 Jul  5 17:08 /dev/fd/0
crw-rw-rw-  1 root  wheel   22,   1 Jul  5 17:08 /dev/fd/1
crw-rw-rw-  1 root  wheel   22,   2 Jul  5 17:08 /dev/fd/2
crw-rw-rw-  1 root  wheel   22,   3 Jul  5 17:08 /dev/fd/3
crw-rw-rw-  1 root  wheel   22,   4 Jul  5 17:08 /dev/fd/4
crw-rw-rw-  1 root  wheel   22,   5 Jul  5 17:08 /dev/fd/5
crw-rw-rw-  1 root  wheel   22,   6 Jul  5 17:08 /dev/fd/6
crw-rw-rw-  1 root  wheel   22,   7 Jul  5 17:08 /dev/fd/7
crw-rw-rw-  1 root  wheel   22,   8 Jul  5 17:08 /dev/fd/8
crw-rw-rw-  1 root  wheel   22,   9 Jul  5 17:08 /dev/fd/9
[...]

However, the horror has been so beaten into the collective unconscious
inherited from earlier days of Unix that shell scripts are still
automatically stripped of any setuid or setgid bits by default on most
Unix variants.  I did see a setuid 'lp' script as a standard part of
the lp system on a Solaris 8 box once -- took me a long time to
convince myself it was actually safe.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   26 The Paddocks
  Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614  Bucks., SL7 1TH UK


pgpanoEr7xQai.pgp
Description: PGP signature


Re: how to make an executable run as another user

2004-09-17 Thread mailing lists at MacTutor
Rich,
Someone else had responded to your post explaining that setuid does not  
work with shell scripts. Nor does it work with any interpreted input.  
The following article might help explain this (and others):

http://www.evolt.org/article/UNIX_File_Permissions_and_Setuid_Part_2/ 
18/263/

QUOTE: "In most UNIX kernels there exists what is called a 'race  
condition' when executing scripts. Scripts are pieces of code which are  
interpreted by, strangely enough, interpreters. Common examples of  
interpreters are perl, sed, and awk. So when you have in your perl code  
#!/usr/local/bin/perl it tells the operating system to start executing  
the perl interpreter with the current script as input. Between the time  
that the perl interpreter starts executing and the time that it reads  
in your script the 'race condition' exists. At this time, a mischievous  
person could 'win the race' and be able to replace your script with  
another. And if your script is running as setuid, that person's script  
would run as your user! So their script could do anything that you  
could do from the command line. As a result, most UNIX kernels will  
disable users from running scripts as setuid. The most common way  
around this is to create a wrapper program around your script. A  
wrapper, in this context, is a small program, possibly written in C,  
that when executed will simply run your script. The 'race condition'  
does not exist for real executables and so you won't be thwarted by the  
kernel itself."

I'm not exceptionally well versed in this stuff. But I think this is  
what you're after.

Alex
On Sep 17, 2004, at 3:50 PM, Richard Bradley wrote:
Um. I feel silly asking this. But I can't work it out.
I want a shell script to run as another user. I always thought this  
was easy
to do with the setuid bit, but never tried it before. I read "man  
chmod" and
found this:

.
4000(the setuid bit).  Executable files with this bit set will
 run with effective uid set to the uid of the file  
owner.
.
s   The set-user-ID-on-execution and set-group-ID-on-execution
   bits.


And off I went. I wrote a shell script to output the current uid. I  
chown'ed
it to another user. I "chmod +s"ed it. I ran it.

It didn't work.
-
rtb27# cat test
#! /bin/sh
whoami
rtb27# ll test
-rwsr-sr-x  1 rich wheel  20 Sep 17 19:34 test
rtb27# ./test
root

Um. Help?

Rich
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to  
"[EMAIL PROTECTED]"


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Alexander Sendzimir (owner)802 863 5502
 MacTutor: Apple Mac OS X Consulting   [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: how to make an executable run as another user

2004-09-17 Thread Bill Moran
Richard Bradley <[EMAIL PROTECTED]> wrote:
> Um. I feel silly asking this. But I can't work it out.

Not silly, common problem for shell script writers.

> I want a shell script to run as another user. I always thought this was easy 
> to do with the setuid bit, but never tried it before. I read "man chmod" and 
> found this:
> 
> .
> 4000(the setuid bit).  Executable files with this bit set will
>  run with effective uid set to the uid of the file owner.
> .
> s   The set-user-ID-on-execution and set-group-ID-on-execution
>bits.
> 
> 
> And off I went. I wrote a shell script to output the current uid. I chown'ed 
> it to another user. I "chmod +s"ed it. I ran it.
> 
> It didn't work.
> 
> -
> 
> rtb27# cat test
> #! /bin/sh
> whoami
> rtb27# ll test
> -rwsr-sr-x  1 rich wheel  20 Sep 17 19:34 test
> rtb27# ./test
> root

Interpreted programs (i.e. scripts) don't honor setuid/setgid (with the
notable exception of setuidperl, which is installed but disabled on
FreeBSD)

Clever use of su or sudo can work around this.  Also, writing a C or
C++ wrapper program will help.  That's a bit of a PITA, though.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: how to make an executable run as another user

2004-09-17 Thread Subhro
man sudo is what you need. Install it from the ports collection

Regards
S.


On Fri, 17 Sep 2004 19:50:19 +, Richard Bradley <[EMAIL PROTECTED]> wrote:
> Um. I feel silly asking this. But I can't work it out.
> 
> I want a shell script to run as another user. I always thought this was easy
> to do with the setuid bit, but never tried it before. I read "man chmod" and
> found this:
> 
> .
> 4000(the setuid bit).  Executable files with this bit set will
> run with effective uid set to the uid of the file owner.
> .
> s   The set-user-ID-on-execution and set-group-ID-on-execution
>   bits.
> 
> 
> And off I went. I wrote a shell script to output the current uid. I chown'ed
> it to another user. I "chmod +s"ed it. I ran it.
> 
> It didn't work.
> 
> -
> 
> rtb27# cat test
> #! /bin/sh
> whoami
> rtb27# ll test
> -rwsr-sr-x  1 rich wheel  20 Sep 17 19:34 test
> rtb27# ./test
> root
> 
> 
> 
> Um. Help?
> 
> Rich
> 
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 



-- 
Subhro Sankha Kar
School of Information Technology
Block AQ-13/1 Sector V
ZIP 700091
India
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"