Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Subtle effects of DOSUID
Message-ID: <7512@jpl-devvax.JPL.NASA.GOV>
Date: 23 Mar 90 00:51:22 GMT
References: <1990Mar21.235646.22870@uvaarpa.Virginia.EDU>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 38

In article <1990Mar21.235646.22870@uvaarpa.Virginia.EDU> tytso@athena.mit.edu writes:
: Because of our setup of where perl is located (which I, unfortunately,
: have no control over), I need to start perl scripts as follows:
: 
: #!/afs/athena.mit.edu/contrib/watchmaker/@sys/perl
: 
: Of course, this doesn't work, because of the kernel limit of 32
: characters for the interpreter name.  So, my standard way of starting
: perl scripts is as follows (yes, I know, what a hack):
: 
: #!/bin/sh
: eval "exec /afs/athena.mit.edu/contrib/watchmaker/@sys/perl -S $0 $*"
:     if $running_under_some_shell;
: 
: Which worked fine, until I tried compiling perl with DOSUID.
: Apparently, one of the checks enabled by DOSUID (which it does even
: though the script is not setuid) is to see if the interpreter
: specified in the #! line is perl --- and if it isn't, to exec the named
: interpreter and feed the script to it.  Of course, this causes a loop
: and perl never gets a chance to execute my script.
: 
: My question is:  why is it doing the check even though the script is not
: setuid?

It has nothing to do with DOSUID.  It would do that even if DOSUID is
undefined.  It does that here, and I don't have it defined at the moment.

We added the #! interpretation feature in patch 9 for people who wanted
to put perl into their SHELL variable for various reasons, but wanted to
be able to start shell scripts with it (such as when running delivermail).

The solution is simple--either delete the #! line entirely, or replace it
with a line beginning with a colon.  On most systems this will force /bin/sh
interpretation.

Or fix your filesystem.  Or fix your kernel.  :-)

Larry