Your message dated Fri, 11 Aug 2017 12:44:51 -0700
with message-id <87o9rlx51o....@iris.silentflame.com>
and subject line Closing inactive Policy bugs
has caused the Debian Bug report #267142,
regarding Specify allowable behavior for /bin/sh shell builtins
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
267142: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267142
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
control: user debian-pol...@packages.debian.org
control: usertag -1 +obsolete
control: tag -1 +wontfix
Russ Allbery and I did a round of in-person bug triage at DebConf17 and
we are closing this bug as inactive.
The reasons for closing fall into the following categories, from most
frequent to least frequent:
- issue is appropriate for Policy, there is a consensus on how to fix
the problem, but preparing the patch is very time-consuming and no-one
has volunteered to do it, and we do not judge the issue to be
important enough to keep an open bug around;
- issue is appropriate for Policy but there does not yet exist a
consensus on what should change, and no recent discussion. A fresh
discussion might allow us to reach consensus, and the messages in the
old bug are unlikely to help very much; or
- issue is not appropriate for Policy.
If you feel this bug is still relevant and want to restart the
discussion, you can re-open the bug. However, please consider instead
opening a new bug with a message that summarises and condenses the
previous discussion, updates the report for the current state of Debian,
and makes clear exactly what you think should change.
A lot of these old bugs have long side tangents and numerous messages,
and that old discussion is not necessarily helpful for figuring out what
Debian Policy should say today.
--
Sean Whitton
signature.asc
Description: PGP signature
--- End Message ---
