[Pkg-sysvinit-devel] Bug#631081: dpkg: please clean environment for maintainer scripts

[Guillem Jover]

forcemerge 18567 631081
retitle 18567 dpkg: clean environment (PATH, etc) for maintainer scripts
thanks

On Tue, 2011-06-21 at 08:50:43 +0200, Raphael Hertzog wrote:
> On Mon, 20 Jun 2011, Witold Baryluk wrote:
> > On 06-20 11:55, Aaron M. Ucko wrote:
> > > As this bug's history shows, a recent libpam-afs-session upgrade made
> > > cron start syslogging errors that turned out to stem from my personal
> > > KRB5CCNAME setting having accidentally leaked into its environment.
> > > (sudo preserves that variable by default, which is appropriate in many
> > > contexts.)  I historically also ran into trouble with leakage from my
> > > TEXMF setting (though I concede that sudo now filters that out itself),
> > > and Russ Allbery mentioned problems with Debconf-related variables
> > > leaking into xinetd invocations and from there ultimately into remote
> > > shells, breaking subsequent aptitude runs.
> > > 
> > > To avoid such surprises, could dpkg please run maintainer scripts in
> > > cleaned enviroments?
> > 
> > I have often problem with TMP or TMPDIR or TEMP leaking from root or other user
> > into dpkg scripts. Removing them will be usefull.

> I think that cleaning the environment will create way more problems than
> what you expect.
> 
> - for a start, the debconf UI might be pre-existing and the environment
>   variables are the way for debconf to know that it's already running
>   and that the postinst doesn't need to restart the UI if it's already
>   there.
> - dropping http_proxy might break maintainer scripts calling wget or
>   similar
> - we obviously don't want to drop LANG and LC_* because we want the user
>   to use his native language parameters
> - we don't want to drop DISPLAY because debconf might want to open a
>   configuration window
> - respecting TMPDIR seems a good idea rather than a bad one
> - etc.

Also PATH and many others which allow the admin to override default
settings (and as such #631081 looks like a superset of #18567, thus
merging).

> Russ Allbery <rra at debian.org> writes:
> > This is a bug that's been bothering me for a long time.  I'm not sure if
> > aptitude or dpkg should be cleaning out the environment before invoking
> > maintainer scripts, maintainer scripts should be cleaning the environment
> > before running invoke-rc.d, or invoke-rc.d should be cleaning the
> > environment, but *something* in that path really should.  In the past,
> 
> I think it should be invoke-rc.d or something below this.
> 
> For dpkg, the only place where it might be helpful is start-stop-daemon. But
> not all packages use start-stop-daemon so I would prefer invoke-rc.d which is
> enshrined in policy.

I don't think s-s-d is the right place, and while this problem affects
mostly long running processes which might spawn childs, those can be
also polluted by direct admin invokation so this is not just a dpkg
issue. This is a general problem specific to daemons for which other
init systems might not be susceptible.

If our standard interfaces for invoking init scripts are service(8) and
invoke-rc.d(8) then I think those two should be in charge of any possible
(and maybe configurable) environment cleanup, if at all.

thanks,
guillem