Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Package: debian-policy
Version: 3.6.1.1
Severity: normal
This arose out of David Weinehall's search for the use of non-Posix
features in package scripts. See bug #260092 for an example, and
#264176 for some of his discussion with me.
Policy 10.4 reminds that "The standard shell interpreter /bin/sh can
be a symbolic link to any POSIX compatible shell....Thus, shell
scripts specifying /bin/sh as interpreter should only use POSIX
features."
And we will note section 6.1, which says: "Programs called from
maintainer scripts should not normally have a path prepended to them."
If you look at bugs #260092 and #264176, you'll see that the complaint
is that the script is using -o and -a as arguments to "test". It is
true that -o and -a are not specified by Posix "test". But--and this
is absolutely crucial--Posix "test" is not part of the Posix shell
specification. As far as Posix is concerned, "test" is simply one
more program.
Because of policy 6.1, we are not supposed to write /usr/bin/test.
What is going on here is that Posix allows a conformant shell to
implement programs as builtins. ANY program. ANY program WHATSOEVER!
Ain't that a kicker? The assumption of Posix is that the shell and
the utilities are being written and distributed by the same people,
and that the shell, when it builds something in, will build it in in a
way which matches the behavior of the utility. But this assumption is
(oddly!) nowhere specified by Posix.
If you install "dash" as /bin/sh on a Debian system, then you break
this assumption.
>From the Posix perspective, there are two kinds of utilities: those
specified to exist by Posix, and those which are extra. A
Posix-conformant shell is allowed to buildin *either* of those. (And
shells liberally take advantage of this, of course.) Posix assumes,
but does not require, that you won't make a buildin which is
inconsistent with a regular program.
For a Posix-specified utility, it is obvious that a Posix-conformant
shell (if it builds it in) must build in a Posix-conformant
implementation of the utility. And dash does do this. But it also
builds in one which is inconsistent with /usr/bin/test on Debian, and
that's a problem.
But I hasten to note that a Posix-conformant shell is allowed to build
in *anything*, and if it's not a Posix-specified utility that's being
built in, then it can have *any behavior whatsoever*. For example, a
Posix-compatible shell may build in a shell command named "debconf",
such that when you run it, it tries deletes everything in /etc. Since
my maintainer scripts are require to work with any Posix-compatible
shell whatsoever, I cannot call debconf from the PATH.
Given Policy as it currently exists, the only way to reliably conform
to section 10.4 is either:
* Never use /bin/sh, ever, as a shell interpereter; or
* Call all programs with fully specified paths to avoid unexpected
builtins.
The second of those solutions conflicts with section 6.1's requirement
not to normally prepend a path. The former seems suboptimal, but does
work. However, Policy as currently worded makes it sound like it is
ever safe to use /bin/sh, and it is not, ever.
David Weinehall proposed one possible fix, to extend 10.4 to restrict
the use not only of non-Posix shell features, but also non-Posix
features in other commands, if those commands are "historically built
in". This is unworkably vague, but can be toned up to something that
does work; see the third option below.
I believe there are four reasonable sorts of policy amendment that
would solve this problem:
OPTION 1: Change 10.4 to require that scripts never use /bin/sh.
OPTION 2: Restrict /bin/sh to a specified list of shells, rather
than "any POSIX compatible shell", and require that shell scripts
run correctly on that list.
OPTION 3: Extend 10.4 to require the use only of Posix features not
only for the shell, but for a specified list of other commands; that
list would be based upon which commands are in fact being built-in
by shells like dash in ways which are inconsistent with the binaries
in /usr/bin.
OPTION 4: Change section 10.4 to require the use of full pathnames
for everything which is not ordered by Posix to be builtin to the
shell; remove the "no pathnames on commands" direction in section
6.1.
I strongly prefer option 2. Options 1 and 3 seem ok to me, with a
slight preference for option 1 because it is more maintainable.
Option 4 is horrible, and you don't need me to say why.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.20-ben10
Locale: LANG=en_US, LC_CTYPE=en_US
-- no debconf information
Reply to: