INTRO (7) NetBSD Miscellaneous Information Manual INTRO (7 ...

SCRIPT (7) NetBSD Miscellaneous Information Manual SCRIPT (7)
"/bin/interp", "-x", "-y", "/tmp/script", "one", "two", "three"
The behavior of the system in the face of multiple arguments is thus not currently standardized, should not be
relied on, and may be changed in future releases. In general, pass at most one argument, and do not rely on
multiple arguments being concatenated.
SEE ALSO
awk(1), csh(1), ksh(1), sh(1), chmod(2), execve(2), intro(2), execlp(3), execvp(3), fd(4),
options(4), setuid(7)
STANDARDS
The behavior of interpreter scripts is obliquely referred to, but never actually described in,
1003.1-2004 " (“POSIX.1”).
IEEE Std
The behavior is partially (but not completely) described in the System V Interface Definition, Fourth Edition
(“SVID4”).
Although it has never been formally standardized, the behavior described is largely portable across POSIX
style systems, with two significant exceptions: the maximum length of the “#!” line, and the behavior if multiple
arguments are passed. Please be aware that some operating systems limit the line to 32 or 64 characters,
and that (as described above) the behavior in the face of multiple arguments is not consistent across systems.
HISTORY
The behavior of the kernel when encountering scripts that start in “#!” was not present in Version 7 AT&T
UNIX. A Usenet posting to net.unix by Guy Harris on October 16, 1984 claims that the idea for the “#!”
behavior was first proposed by Dennis Ritchie but that the first implementation was on BSD.
Historical manuals (specifically the exec man page) indicate that the behavior was present in 4BSD at least as
early as April, 1981. Information on precisely when it was first implemented, and in which version of UNIX,
is solicited.
SECURITY CONSIDERATIONS
Numerous security problems are associated with setuid interpreter scripts.
In addition to the fact that many interpreters (and scripts) are simply not designed to be robust in a setuid
context, a race condition exists between the moment that the kernel examines the interpreter script file and
the moment that the newly invoked interpreter opens the file itself.
Because of these security issues, NetBSD does not allow setuid interpreter scripts by default. In order to turn
on setuid interpreter scripts,
options SETUIDSCRIPTS
must be set in the configuration of the running kernel. Setting this option implies the FDSCRIPTS option,
which causes the kernel to open the script file on behalf of the interpreter and pass it in argv as
/dev/fd/[fdnum]. (See fd(4) for an explanation of the /dev/fd/[fdnum] devices.) This design
avoids the race condition, at the cost of denying the interpreter the actual name of the script file. See
options(4) for more information.
However, the FDSCRIPTS mechanism is not a cure-all for security issues in setuid interpreters and scripts.
Subtle techniques can be used to subvert even seemingly well written scripts. Scripts executed by Bourne
type shells can be subverted in numerous ways, such as by setting the IFS variable before executing the
script. Other interpreters possess their own vulnerabilities. Turning on SETUIDSCRIPTS is therefore very
dangerous, and should not be done lightly if at all.
NetBSD 3.0 May 6, 2005 3