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 <r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
