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

[Russ Allbery]

Control: tags -1 = pending

Niels Thykier  writes:
> On Sun, 25 Jun 2017 14:58:06 -0700 Russ Allbery  wrote:

>> Everyone seemed generally happy with this text, but it never clearly got
>> enough seconds to apply.  Here's an updated patch so that we can take
>> another run at getting enough seconds and getting it merged.

> Seconded,  thanks for writing it. :)

Thanks, both.  This has now been applied for the next release.

-- 
Russ Allbery (r...@debian.org)   

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

[Debian Bug Tracking System]

Processing control commands:

> tags -1 = pending
Bug #640263 [debian-policy] Clarify 9.9 - Environment variables
Added tag(s) pending; removed tag(s) patch.

-- 
640263: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640263
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Niels Thykier]

On Sun, 25 Jun 2017 14:58:06 -0700 Russ Allbery  wrote:
> Russ Allbery  writes:
> 
> > Looking at this section, there are several issues.  One is the issue
> > addressed above, and I like Jonathan's wording for that.  Another is the
> > one Colin mentioned earlier: this only applies to programs installed in
> > the system path.  (I considered saying programs intended to be directly
> > invoked by users, but I can imagine pointless arguments about /usr/sbin
> > programs, so let's just go with that.)  A third issue is that parts of
> > that section are now out of date, since /etc/profile.d exists (but still
> > shouldn't be used for this purpose).
> 
> > I propose the attached patch to address all of those issues.  Seconds or
> > further discussion?
> 
> Hi folks,
> 
> Everyone seemed generally happy with this text, but it never clearly got
> enough seconds to apply.  Here's an updated patch so that we can take
> another run at getting enough seconds and getting it merged.
> 

Seconded,  thanks for writing it. :)

> diff --git a/policy.xml b/policy.xml
> index 7ba5fc0..ace6a3b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -9352,11 +9352,14 @@ Reloading description 
> configuration...done.
>Environment variables
>  
>
> -A program must not depend on environment variables to get
> -reasonable defaults.  (That's because these environment variables
> -would have to be set in a system-wide configuration file like
> -/etc/profile, which is not supported by all
> -shells.)
> +Programs installed on the system PATH (/bin,
> +/usr/bin, /sbin,
> +/usr/sbin, or similar directories) must not
> +depend on custom environment variable settings to get reasonable
> +defaults.  This is because such environment variables would have
> +to be set in a system-wide configuration file such as a file in
> +/etc/profile.d, which is not supported by all
> +shells.
>
>
>  If a program usually depends on environment variables for its
> @@ -9364,7 +9367,7 @@ Reloading description 
> configuration...done.
>  reasonable default configuration if these environment variables
>  are not present.  If this cannot be done easily (e.g., if the
>  source code of a non-free program is not available), the program
> -must be replaced by a small "wrapper" shell script which sets the
> +must be replaced by a small "wrapper" shell script that sets the
>  environment variables if they are not already defined, and calls
>  the original program.
>
> @@ -9377,12 +9380,6 @@ BAR=${BAR:-/var/lib/fubar}
>  export BAR
>  exec /usr/lib/foo/foo "$@"
>
> -  
> -Furthermore, as /etc/profile is a
> -configuration file of the base-files package,



signature.asc
Description: OpenPGP digital signature

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

[Simon McVittie]

On Sun, 25 Jun 2017 at 14:58:06 -0700, Russ Allbery wrote:
> Everyone seemed generally happy with this text, but it never clearly got
> enough seconds to apply.  Here's an updated patch so that we can take
> another run at getting enough seconds and getting it merged.

I second the patch quoted below.

> diff --git a/policy.xml b/policy.xml
> index 7ba5fc0..ace6a3b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -9352,11 +9352,14 @@ Reloading description 
> configuration...done.
>Environment variables
>  
>
> -A program must not depend on environment variables to get
> -reasonable defaults.  (That's because these environment variables
> -would have to be set in a system-wide configuration file like
> -/etc/profile, which is not supported by all
> -shells.)
> +Programs installed on the system PATH (/bin,
> +/usr/bin, /sbin,
> +/usr/sbin, or similar directories) must not
> +depend on custom environment variable settings to get reasonable
> +defaults.  This is because such environment variables would have
> +to be set in a system-wide configuration file such as a file in
> +/etc/profile.d, which is not supported by all
> +shells.
>
>
>  If a program usually depends on environment variables for its
> @@ -9364,7 +9367,7 @@ Reloading description 
> configuration...done.
>  reasonable default configuration if these environment variables
>  are not present.  If this cannot be done easily (e.g., if the
>  source code of a non-free program is not available), the program
> -must be replaced by a small "wrapper" shell script which sets the
> +must be replaced by a small "wrapper" shell script that sets the
>  environment variables if they are not already defined, and calls
>  the original program.
>
> @@ -9377,12 +9380,6 @@ BAR=${BAR:-/var/lib/fubar}
>  export BAR
>  exec /usr/lib/foo/foo "$@"
>
> -  
> -Furthermore, as /etc/profile is a
> -configuration file of the base-files package,
> -other packages must not put any environment variables or other
> -commands into that file.
> -  
>  
>  
>  

Regards,
S

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

[Russ Allbery]

Russ Allbery  writes:

> Looking at this section, there are several issues.  One is the issue
> addressed above, and I like Jonathan's wording for that.  Another is the
> one Colin mentioned earlier: this only applies to programs installed in
> the system path.  (I considered saying programs intended to be directly
> invoked by users, but I can imagine pointless arguments about /usr/sbin
> programs, so let's just go with that.)  A third issue is that parts of
> that section are now out of date, since /etc/profile.d exists (but still
> shouldn't be used for this purpose).

> I propose the attached patch to address all of those issues.  Seconds or
> further discussion?

Hi folks,

Everyone seemed generally happy with this text, but it never clearly got
enough seconds to apply.  Here's an updated patch so that we can take
another run at getting enough seconds and getting it merged.

diff --git a/policy.xml b/policy.xml
index 7ba5fc0..ace6a3b 100644
--- a/policy.xml
+++ b/policy.xml
@@ -9352,11 +9352,14 @@ Reloading description 
configuration...done.
   Environment variables
 
   
-A program must not depend on environment variables to get
-reasonable defaults.  (That's because these environment variables
-would have to be set in a system-wide configuration file like
-/etc/profile, which is not supported by all
-shells.)
+Programs installed on the system PATH (/bin,
+/usr/bin, /sbin,
+/usr/sbin, or similar directories) must not
+depend on custom environment variable settings to get reasonable
+defaults.  This is because such environment variables would have
+to be set in a system-wide configuration file such as a file in
+/etc/profile.d, which is not supported by all
+shells.
   
   
 If a program usually depends on environment variables for its
@@ -9364,7 +9367,7 @@ Reloading description 
configuration...done.
 reasonable default configuration if these environment variables
 are not present.  If this cannot be done easily (e.g., if the
 source code of a non-free program is not available), the program
-must be replaced by a small "wrapper" shell script which sets the
+must be replaced by a small "wrapper" shell script that sets the
 environment variables if they are not already defined, and calls
 the original program.
   
@@ -9377,12 +9380,6 @@ BAR=${BAR:-/var/lib/fubar}
 export BAR
 exec /usr/lib/foo/foo "$@"
   
-  
-Furthermore, as /etc/profile is a
-configuration file of the base-files package,
-other packages must not put any environment variables or other
-commands into that file.
-  
 
 
 

-- 
Russ Allbery (r...@debian.org)   

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

[Bill Allombert]

On Thu, Nov 14, 2013 at 02:38:37AM +0100, Carl Fürstenberg wrote:
 On Mon, Jul 9, 2012 at 4:07 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 
  What happened to this proposal?  Does it need attention from any
  particular affected audience (maybe the base-files maintainer or
  people familiar with the system initialization process)?
 
 
 Seems nothing has happened last year and a half :/
 While I feel the clarification in the bug replies are sufficient, I would
 think it would be good to have the patch applied.

Would you mind explicitly second it ?
This would clarify which patch you would like to see applied.

Thanks in advance.
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150508165901.GA16506@yellowpig

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

[Carl Fürstenberg]

On Mon, Jul 9, 2012 at 4:07 AM, Jonathan Nieder jrnie...@gmail.com wrote:

 What happened to this proposal?  Does it need attention from any
 particular affected audience (maybe the base-files maintainer or
 people familiar with the system initialization process)?


Seems nothing has happened last year and a half :/
While I feel the clarification in the bug replies are sufficient, I would
think it would be good to have the patch applied.

-- 
Carl Fürstenberg

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

[Charles Plessy]

Le Thu, Nov 14, 2013 at 02:38:37AM +0100, Carl Fürstenberg a écrit :
 
 Seems nothing has happened last year and a half :/
 While I feel the clarification in the bug replies are sufficient, I would
 think it would be good to have the patch applied.

Hello everybody,

note that in the meantime, another section introduced a similar definition of
the system PATH.

  sect id=filenames
headingFile names/heading

p
  The name of the files installed by binary packages in the system PATH
  (namely tt/bin/tt, tt/sbin/tt, tt/usr/bin/tt,
  tt/usr/sbin/tt and tt/usr/games/tt) must be encoded in
  ASCII.
/p

While I have no objections on applying this bugs report's patch, it would be
even better to have a unique definition in the Policy. 

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131114015559.gd18...@falafel.plessy.net

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

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

 I propose the attached patch to address all of those issues.  Seconds or
 further discussion?
[...]
  policy.sgml |   24 ++--
  1 files changed, 10 insertions(+), 14 deletions(-)

What happened to this proposal?  Does it need attention from any
particular affected audience (maybe the base-files maintainer or
people familiar with the system initialization process)?

Patch left unsnipped for reference.

 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -7450,11 +7450,14 @@ Reloading vardescription/var configuration...done.
   headingEnvironment variables/heading
  
   p
 -   A program must not depend on 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.)
 +   Programs installed on the system PATH
 +   (file/bin/file, file/usr/bin/file, file/sbin/file,
 +   file/usr/sbin/file, or similar directories) must not depend
 +   on custom environment variable settings to get reasonable
 +   defaults.  This is because such environment variables would have
 +   to be set in a system-wide configuration file such as a file
 +   in file/etc/profile.d/file, which is not supported by all
 +   shells.
   /p
  
   p
 @@ -7464,8 +7467,8 @@ Reloading vardescription/var configuration...done.
 variables are not present. If this cannot be done easily
 (e.g., if the source code of a non-free program is not
 available), the program must be replaced by a small
 -   wrapper shell script which sets the environment variables
 -   if they are not already defined, and calls the original program.
 +   wrapper shell script that sets the environment variables
 +   if they are not already defined and calls the original program.
   /p
  
   p
 @@ -7478,13 +7481,6 @@ export BAR
  exec /usr/lib/foo/foo $@
 /example
   /p
 -
 - p
 -   Furthermore, as file/etc/profile/file is a configuration
 -   file of the prgnbase-files/prgn package, other packages must
 -   not put any environment variables or other commands into that
 -   file.
 - /p
/sect
  
sect id=doc-base
 -- 
 1.7.7.3




-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120709020749.GA15113@burratino

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

[Russ Allbery]

Jonathan Nieder jrnie...@gmail.com writes:
 Colin Watson wrote:

 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -7449,8 +7449,8 @@ Reloading vardescription/var configuration...done.
  headingEnvironment 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.)

 Thanks!  With s/environment variables/environment variable settings/ to
 make it clearer that this includes cases like
 PATH=/opt/myprog/bin:$PATH, sounds good to me, for what its worth.

[...]

 Maybe dropping its own would take care of it.  That would make:

   A program must not depend on custom environment variable settings
   to get reasonable defaults.  (That's because ...

Looking at this section, there are several issues.  One is the issue
addressed above, and I like Jonathan's wording for that.  Another is the
one Colin mentioned earlier: this only applies to programs installed in
the system path.  (I considered saying programs intended to be directly
invoked by users, but I can imagine pointless arguments about /usr/sbin
programs, so let's just go with that.)  A third issue is that parts of
that section are now out of date, since /etc/profile.d exists (but still
shouldn't be used for this purpose).

I propose the attached patch to address all of those issues.  Seconds or
further discussion?

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/

From a99c511daaa8fa165af8a64cc4dc4618258aad24 Mon Sep 17 00:00:00 2001
From: Russ Allbery r...@debian.org
Date: Sat, 24 Dec 2011 10:10:56 -0800
Subject: [PATCH] Improve environment variable restrictions for programs

The restrictions on not using environment variables refers to custom
environment variables (not, say, PATH), and only applies to programs
installed on the system PATH.

Also update the wording to reflect that /etc/profile.d is now
available, but still cannot be used for this purpose.  Remove the
paragraph explaining that /etc/profile is a base-files configuration
file, since /etc/profile.d solves that problem and it's not the point.
---
 policy.sgml |   24 ++--
 1 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 4aeae36..39378f9 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7450,11 +7450,14 @@ Reloading vardescription/var configuration...done.
 	headingEnvironment variables/heading
 
 	p
-	  A program must not depend on 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.)
+	  Programs installed on the system PATH
+	  (file/bin/file, file/usr/bin/file, file/sbin/file,
+	  file/usr/sbin/file, or similar directories) must not depend
+	  on custom environment variable settings to get reasonable
+	  defaults.  This is because such environment variables would have
+	  to be set in a system-wide configuration file such as a file
+	  in file/etc/profile.d/file, which is not supported by all
+	  shells.
 	/p
 
 	p
@@ -7464,8 +7467,8 @@ Reloading vardescription/var configuration...done.
 	  variables are not present. If this cannot be done easily
 	  (e.g., if the source code of a non-free program is not
 	  available), the program must be replaced by a small
-	  wrapper shell script which sets the environment variables
-	  if they are not already defined, and calls the original program.
+	  wrapper shell script that sets the environment variables
+	  if they are not already defined and calls the original program.
 	/p
 
 	p
@@ -7478,13 +7481,6 @@ export BAR
 exec /usr/lib/foo/foo $@
 	  /example
 	/p
-
-	p
-	  Furthermore, as file/etc/profile/file is a configuration
-	  file of the prgnbase-files/prgn package, other packages must
-	  not put any environment variables or other commands into that
-	  file.
-	/p
   /sect
 
   sect id=doc-base
-- 
1.7.7.3

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

[Jonathan Nieder]

Russ Allbery wrote:

 I propose the attached patch to address all of those issues.  Seconds or
 further discussion?

Looks good to me.  (Well, one nit: the log message says

custom environment variables (not, say, PATH)

where I think the intent is something like

custom environment variable settings (not, say, a sensible
PATH)

One way to avoid that would be to just leave the summary out.)



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111224194613.GD25883@elie.Belkin

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

[Jonathan Nieder]

Colin Watson wrote:

 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 vardescription/var configuration...done.
   headingEnvironment 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.)

Thanks!  With s/environment variables/environment variable settings/ to
make it clearer that this includes cases like PATH=/opt/myprog/bin:$PATH,
sounds good to me, for what its worth.

 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?

Maybe dropping its own would take care of it.  That would make:

A program must not depend on custom environment variable settings
to get reasonable defaults.  (That's because ...



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915210951.GA31820@elie

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

[Carl Fürstenberg]

Package: debian-policy
Version: 3.9.2.0
Severity: normal

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.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.10.2 utilities to manage online documen

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110903172416.3842.93725.report...@azaboxen.carl

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

[Jonathan Nieder]

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.



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110903180842.GB24034@elie

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

[Jonathan Nieder]

Jonathan Nieder wrote:

 See /usr/bin/iceweasel for an example

Scratch that --- iceweasel can be run directly nowadays as
/usr/lib/iceweasel/firefox-bin.  I should have said see pre-2010
mozilla for an example involving LD_LIBRARY_PATH.

https://bugzilla.mozilla.org/show_bug.cgi?id=552864

Happily,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110903183747.GA28684@elie

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

[Colin Watson]

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 vardescription/var configuration...done.
headingEnvironment 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