xxrich@alliant1.lerc.nasa.gov (Rich Rinehart) (11/15/90)
Could anyone shed some light on this and give me a workaround? I am trying to set owner of a script to root, and it will not work: chmod 4555 <script name> (<script name> is owned by root) then running <script name> from a general userid gives me: <script name>: Permission denied. The same procedure works fine for a binary program (try it on /usr/alliant/setcomplex for example). It also works fine for scripts on other computer systems. Am I missing something?? Thanks! -- ----------------------------------------------------------------------------- Rich Rinehart | phone: 216-433-5211 NASA Lewis Research Center | email: xxrich@alliant1.lerc.nasa.gov -----------------------------------------------------------------------------
wswietse@svbs01.bs.win.tue.nl (Wietse Venema) (11/23/90)
xxrich@alliant1.lerc.nasa.gov (Rich Rinehart) writes:
#Could anyone shed some light on this and give me a workaround? I am
#trying to set owner of a script to root, and it will not work:
#
#chmod 4555 <script name> (<script name> is owned by root)
#
#then running <script name> from a general userid gives me:
#
#<script name>: Permission denied.
Good thing. Set-uid shell scripts are an evil thing. It takes just two
commands to fool the system into giving someone an interactive shell.
Hint: sh -i. Have a look at recent discussions in comp.unix.whatever
about this topic.henkel%nepjt@ncsuvx.ncsu.edu (Chuck Henkel) (11/24/90)
xxrich@alliant1.lerc.nasa.gov (Rich Rinehart) writes: > #Could anyone shed some light on this and give me a workaround? I am > #trying to set owner of a script to root, and it will not work: > # > #chmod 4555 <script name> (<script name> is owned by root) > # > #then running <script name> from a general userid gives me: > # > #<script name>: Permission denied. From the release notes for Concentrix v5.6 (p. 12, under the heading "Changes Included in v5.5.03"): - Disallowed the execution of scripts with either the "setuid" or "setgid" bit set. This change may be overridden by setting the kernel variable "suid_script" to 1. This is probably what's biting you. I have no idea how to set this kernel variable. Aside: Note that they finally fixed the "write" command simply by changing it's mode and ownership. Aargh! That bug has driven me crazy since we got this thing. -- | Chuck Henkel | | | N.C. State University | Curious about evolution? | | Department of Nuclear Engineering | Read Stephen J. Gould. | | henkel%nepjt@ncsuvx.ncsu.edu | |
guy@auspex.auspex.com (Guy Harris) (11/30/90)
>Good thing. Set-uid shell scripts are an evil thing. It takes just two >commands to fool the system into giving someone an interactive shell. >Hint: sh -i. Have a look at recent discussions in comp.unix.whatever >about this topic. Well, actually, if you make the "#!" line read as "#! /bin/sh -" rather than "#! /bin/sh", the particular trick to which you're referring won't work. However, in most systems that support the usual form of "#!", it takes just one program and one command to fool the system into giving someone an interactive shell, and there's no way to set up your shell script so that you can't fool the system - it requires cooperation on the part of whatever implements "#!" (typically the kernel), and that cooperation isn't provided by most UNIX systems (System V Release 4 provides it, as will, I think, 4.4BSD). There are other mechanisms for providing set-UID shell scripts that may also close that particular hole, e.g. a program Maarten Litmath wrote (which is mentioned in the aforementioned recent discussions). However, note that, just as set-UID *programs* have to be written carefully to make sure they don't contain security holes, set-UID *shell scripts* have to be written carefully as well - and, given that shells tend to be relatively large programs implementing reasonably powerful languages, it may be difficult to know whether you've closed every possible security hole. (Did you remember to set "IFS", if the script is a Bourne/Korn/Bourne-again script? What about setting "PATH"?)