1 .\" $NetBSD: script.7,v 1.4 2007/03/01 19:35:47 wiz Exp $
3 .\" Copyright (c) 2005 The NetBSD Foundation, Inc.
4 .\" All rights reserved.
6 .\" This document was originally contributed to The NetBSD Foundation
7 .\" by Perry E. Metzger of Metzger, Dowdeswell & Co. LLC.
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\" notice, this list of conditions and the following disclaimer.
14 .\" 2. Redistributions in binary form must reproduce the above copyright
15 .\" notice, this list of conditions and the following disclaimer in the
16 .\" documentation and/or other materials provided with the distribution.
18 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21 .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28 .\" POSSIBILITY OF SUCH DAMAGE.
35 .Nd interpreter script execution
37 The system is capable of treating a text file containing commands
38 intended for an interpreter, such as
42 as an executable program.
45 .Dq interpreter script
46 is a file which has been set executable (see
48 and which has a first line of the form:
50 .D1 Li #! Ar pathname Op Ar argument
54 must appear as the first two characters of the file.
64 and the length of the entire line is limited (see below).
66 If such a file is executed (such as via the
68 system call), the interpreter specified by the
70 is executed by the system.
73 is executed without regard to the
75 variable, so in general
77 should be an absolute path.)
79 The arguments passed to the interpreter will be as follows.
81 will be the path to the interpreter itself, as specified on the first
87 on the first line of the script, it will be passed as
89 The subsequent elements of
91 will be the path to the interpreter script file itself (i.e. the
94 followed by any further arguments passed when
96 was invoked to execute the script file.
98 By convention, it is expected that an interpreter will open the script
99 file passed as an argument and process the commands within it.
100 Typical interpreters treat
102 as a comment character, and thus will ignore the initial line of the script
105 but there is no requirement for this per se.
113 itself, is limited to
117 Other operating systems impose much smaller limits on the length of
122 Note that the interpreter may not itself be an interpreter script.
125 does not point to an executable binary, execution of the interpreter
127 .Ss Trampolines and Portable Scripts
128 Different operating systems often have interpreters located in
129 different locations, and the kernel executes the passed interpreter
130 without regard to the setting of environment variables such as
132 This makes it somewhat challenging to set the
134 line of a script so that it will run identically on different systems.
138 utility executes a command passed to it on its command line, it is
141 to render scripts portable.
142 If the leading line of a script reads
143 .Dl #! /usr/bin/env interp
146 command will execute the
148 command it finds in its
150 passing on to it all subsequent arguments with which it itself was called.
153 is found on almost all
155 style systems, this trick is frequently exploited by authors who need
156 a script to execute without change on multiple systems.
157 .Ss Historical Note: Scripts without Dq #!
158 Shell scripts predate the invention of the
160 convention, which is implemented in the kernel.
163 there was only one interpreter used on the system,
165 and the shell treated any file that failed to execute with an
174 and certain other facilities (including
178 but not other types of
181 interpreter scripts that do not include the
183 (and thus fail to execute with
188 As this behavior is implemented outside the kernel, there is no
189 mechanism that forces it to be respected by all programs that execute
191 It is thus not completely reliable.
192 It is therefore important to always include
194 in front of Bourne shell scripts, and to treat the traditional
195 behavior as obsolete.
197 Suppose that an executable binary exists in
202 .Bd -literal -offset indent
214 .Dl $ /tmp/script one two three
216 at the shell will result in
218 being executed, receiving the following arguments in
222 .Bd -ragged -offset indent
230 .Ss Portability Note: Multiple arguments
231 The behavior of multiple arguments on the
233 line is highly non-portable between different systems.
234 In general, only one argument can be assumed to work consistently.
236 Consider the following variation on the previous example.
237 Suppose that an executable binary exists in
242 .Bd -literal -offset indent
254 .Dl $ /tmp/script one two three
256 at the shell will result in
258 being executed, receiving the following arguments in
262 .Bd -ragged -offset indent
275 as a single argument.
279 style operating systems will pass only one
281 the behavior when multiple arguments are included is not
282 consistent between platforms.
283 Some, such as current releases of
285 will concatenate multiple arguments into a single argument (as above),
286 some will truncate them, and at least one will pass them as multiple
291 behavior is common but not universal.
294 would present the above argument as
299 Perhaps uniquely, recent versions of Apple's
301 will actually pass multiple arguments properly, i.e.:
302 .Bd -ragged -offset indent
312 The behavior of the system in the face of multiple arguments is thus
313 not currently standardized, should not be relied on, and may be
314 changed in future releases.
315 In general, pass at most one argument, and do not rely on multiple
316 arguments being concatenated.
331 The behavior of interpreter scripts is obliquely referred to, but
332 never actually described in,
335 The behavior is partially (but not completely) described in the
338 Although it has never been formally standardized, the behavior
339 described is largely portable across
341 style systems, with two significant exceptions: the maximum length of the
343 line, and the behavior if multiple arguments are passed.
344 Please be aware that some operating systems limit the line to 32
345 or 64 characters, and that (as described above) the behavior in the
346 face of multiple arguments is not consistent across systems.
348 The behavior of the kernel when encountering scripts that start in
352 A Usenet posting to net.unix by Guy Harris on October 16, 1984 claims
353 that the idea for the
355 behavior was first proposed by Dennis Ritchie but that the first
356 implementation was on
359 Historical manuals (specifically the exec man page) indicate that the
360 behavior was present in
362 at least as early as April, 1981.
363 Information on precisely when it was first implemented, and in which
367 .Sh SECURITY CONSIDERATIONS
368 Numerous security problems are associated with setuid interpreter
371 In addition to the fact that many interpreters (and scripts) are
372 simply not designed to be robust in a setuid context, a race condition
373 exists between the moment that the kernel examines the interpreter
374 script file and the moment that the newly invoked interpreter opens
377 Because of these security issues,
379 does not allow setuid interpreter scripts by default.
380 In order to turn on setuid interpreter scripts,
381 .D1 Cd options SETUIDSCRIPTS
382 must be set in the configuration of the running kernel.
383 Setting this option implies the
385 option, which causes the kernel to open the script file on behalf of
386 the interpreter and pass it in
389 .Pa /dev/fd/[fdnum] .
392 for an explanation of the
395 This design avoids the race condition, at the cost of denying the
396 interpreter the actual name of the script file.
399 for more information.
403 mechanism is not a cure-all for security issues in setuid interpreters
405 Subtle techniques can be used to subvert even seemingly well written scripts.
406 Scripts executed by Bourne type shells can be subverted in numerous
407 ways, such as by setting the
409 variable before executing the script.
410 Other interpreters possess their own vulnerabilities.
413 is therefore very dangerous, and should not be done lightly if at all.