Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Carl,

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.

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.

Clearing the environment is a whole other story[1].

Hope that helps,
Jonathan

[1] In practice, many programs do not behave well when the environment
is cleared with "env -i".  For example, consider the following:

	#include <stdio.h>
	#include <stdlib.h>
	#include <unistd.h>

	int main(void)
	{
		printf("%s\n", getenv("HOME"));
		execlp("ls", "ls", NULL);
		return 0;
	}

When this is run with "env -i", the printf converted to puts by gcc
would segfault; even worse, the execlp would behave as though PATH
were ".:$(getconf PATH)" and happily run whatever random "ls"
executable happens to be in the cwd.

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.