Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables
On Sat, Sep 03, 2011 at 01:08:42PM -0500, Jonathan Nieder wrote:
> Carl Fürstenberg wrote:
> > Per resolution of bug #639997 I would like to ask for clarification of
> > section 9.9 in the polcy regarding environmental variables, and if it
> > implicitly excludes "global" environmental variables like PATH, or if
> > all programs must include themself a sensible default PATH as fallback.
>
> The intent of policy §9.9 seems to be disallow a public-facing program
> that requires adding
>
> PATH=/opt/my-program/bin:$PATH
>
> to /etc/profile in order to work correctly (yes, such programs exist!
> See /usr/bin/iceweasel for an example --- firefox-bin --- of a similar
> kind of program). From that point of view, it should be clear that it
> is not the intent of the current policy to force maintainers' hands in
> cases like #639997.
Agreed. The point was to avoid the situation where individual packages
come with instructions to edit your .bashrc or similar before they would
work at all - regrettably not an uncommon practice among developers who
haven't thought about how that doesn't scale up sensibly - not to forbid
packages relying on the usual environment that any process gets unless
you take special measures to prevent it doing so.
Note in particular that init sets a reasonable default PATH, as does
anything that starts a PAM session, so something has to be deliberately
awkward to unset that. It would be actively harmful for every program
to set its own default PATH to defend against this particular species of
awkwardness, because then we would have to run around trying to make
sure that all those default PATH settings were consistent. Falling back
to standard library behaviour (such as the execlp default you mention)
or exiting with an error message both seem perfectly reasonable
responses to me.
Incidentally, although policy is not explicit on the subject, I also
think that this (much like the admonition in 10.4 about script
extensions) clearly only applies to programs installed on the system
PATH and thus intended to be called directly by users. I see no problem
with a program in /usr/lib/$package/ that expects to be called by some
other program with a particular environment, or with a CGI script that
expects to be called with the usual CGI environment variables set by web
servers.
> Can you think of an alternative phrasing that makes that clearer? To
> be clear: the content of the environment is not supposed to be
> harmless or irrelevant to all programs. For example, a bad setting
> for PATH, EDITOR, or LD_PRELOAD is going to break almost anything, and
> that's _good_ (because predictable). The only point here is that
> programs should not require special settings (e.g., extra PATH
> entries) of their own in order to run correctly, so they can be used
> out of the box.
Yes. How about:
diff --git a/policy.sgml b/policy.sgml
index bb424ed..3a8bd90 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7449,8 +7449,8 @@ Reloading <var>description</var> configuration...done.
<heading>Environment variables</heading>
<p>
- A program must not depend on environment variables to get
- reasonable defaults. (That's because these environment
+ A program must not depend on its own custom environment variables
+ to get reasonable defaults. (That's because these environment
variables would have to be set in a system-wide
configuration file like <file>/etc/profile</file>, which is not
supported by all shells.)
My only concern is that people might rules-lawyer about how
such-and-such an environment variable isn't specific to a single program
but a group of programs and so is somehow not covered by this; JAVA_HOME
comes to mind. Do we need to be explicit about this or is it clear
enough?
There are actually very few environment variables that I think a program
can absolutely rely on being present (as opposed to breaking if they're
set to crazy values; that's not what 9.9 is talking about), so maybe we
can just enumerate the exceptions. The only ones that come to mind are
PATH, TERM, and possibly HOME. But maybe this is a can of worms; having
an enumerated list that looks as though it should be complete but in
fact isn't would be bad. Better, surely, to set general expectations
and allow the use of common sense.
> Depending on the program, some misbehaviors of this kind may be bugs
> and others may not. In this example, the segfault feels like a bug
> while respecting a lack-of-PATH is just a historical misfeature,
> unless the program can be used for privilege escalation that way, in
> which case the lack of PATH scrubbing would have been a serious bug
> already. I haven't thought carefully about whether the line between
> is worth documenting in policy.
I agree with your gut feel about where the line goes, but I think this
is already likely to be clear enough to competent developers and so I
don't particularly feel this needs documenting in policy. Unless Carl
has an explicit real-world situation in mind, the case of an unset PATH
seems contrived enough that I don't think policy needs to spell out its
exact behaviour in detail.
In the particular case of #639997, I would also note that dpkg is acting
to ensure that this statement in policy 6.1 holds, which serves to avoid
maintainer scripts needing to be peppered with fragile absolute paths
all over the place:
Before installation is started, the package management system checks
to see if the programs ldconfig, start-stop-daemon, install-info, and
update-rc.d can be found via the PATH environment variable.
Thus, independent of this discussion, dpkg has specific authorisation
from policy to perform the check in question. 6.1 goes on to say:
Maintainer scripts should also not reset the PATH, though they might
choose to modify it by prepending or appending package-specific
directories. These considerations really apply to all shell scripts.
This clearly supports the position that programs do not need to take
special measures to set their own PATH.
--
Colin Watson [cjwatson@debian.org]
Reply to: