Debian Bug report logs - #631081
dpkg: clean environment (PATH, etc) for maintainer scripts

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Aaron M. Ucko" <ucko@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libpam-afs-session: logs aklog failures for cron jobs

Date: Sun, 19 Jun 2011 20:26:27 -0400

Package: libpam-afs-session
Version: 2.4-1
Severity: minor

Since upgrading libpam-afs-session from version 2.2-1 to version
2.4-1, I've found that cron's invocations thereof (thanks to its
presence in /etc/pam.d/common-session-noninteractive) result in syslog
messages of the form

Jun 19 17:15:01 tux64 CRON[2471]: pam_afs_session(cron:session): aklog program /usr/bin/aklog returned 4

which logcheck conservatively considers noteworthy.  Could you please
adjust it to do nothing, or at least not whine if aklog fails, if
there's no sign that it has any actual tickets to work with?

Thanks!

P.S.: the jobs responsible for most of the noise run as users with
uids less than 1000, which pam_krb5.so is configured to ignore.

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

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

Versions of packages libpam-afs-session depends on:
ii  libc6                    2.13-4          Embedded GNU C Library: Shared lib
ii  libkrb5-3                1.9.1+dfsg-1+b1 MIT Kerberos runtime libraries
ii  libpam-runtime           1.1.3-1         Runtime support for the PAM librar
ii  libpam0g                 1.1.2-2         Pluggable Authentication Modules l

Versions of packages libpam-afs-session recommends:
ii  libpam-krb5                 4.4-1        PAM module for MIT Kerberos
ii  openafs-client              1.6.0~pre4-1 AFS distributed filesystem client 
ii  openafs-krb5                1.6.0~pre4-1 AFS distributed filesystem Kerbero

libpam-afs-session suggests no packages.

-- no debconf information

Message #10 received at 631081@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: "Aaron M. Ucko" <ucko@debian.org>

Cc: 631081@bugs.debian.org

Subject: Re: Bug#631081: libpam-afs-session: logs aklog failures for cron jobs

Date: Sun, 19 Jun 2011 17:36:23 -0700

"Aaron M. Ucko" <ucko@debian.org> writes:

> Since upgrading libpam-afs-session from version 2.2-1 to version
> 2.4-1, I've found that cron's invocations thereof (thanks to its
> presence in /etc/pam.d/common-session-noninteractive) result in syslog
> messages of the form

> Jun 19 17:15:01 tux64 CRON[2471]: pam_afs_session(cron:session): aklog program /usr/bin/aklog returned 4

> which logcheck conservatively considers noteworthy.  Could you please
> adjust it to do nothing, or at least not whine if aklog fails, if
> there's no sign that it has any actual tickets to work with?

Why is your crond running with KRB5CCNAME set in its environment?  I
suspect that at some point you restarted crond with a dirty environment,
probably from a user login....

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

Message #15 received at 631081@bugs.debian.org (full text, mbox, reply):

From: ucko@debian.org (Aaron M. Ucko)

To: Russ Allbery <rra@debian.org>

Cc: "Aaron M. Ucko" <ucko@debian.org>, 631081@bugs.debian.org

Subject: Re: Bug#631081: libpam-afs-session: logs aklog failures for cron jobs

Date: Sun, 19 Jun 2011 21:52:14 -0400

Hi, Russ!  Thanks for the quick response.

Russ Allbery <rra@debian.org> writes:

> Why is your crond running with KRB5CCNAME set in its environment?  I
> suspect that at some point you restarted crond with a dirty environment,
> probably from a user login....

Good question; it looks like my (mostly default) sudo configuration
leaks KRB5CCNAME, so a recent run of sudo aptitude safe-upgrade that
resulted in restarting cron caused it to pick up my personal setting
thereof. :-/  I'll adjust my setup to avoid that, but still feel it's
enough of a gotcha that more widespread changes might be in order.

Thanks.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #20 received at 631081@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: ucko@debian.org (Aaron M. Ucko)

Cc: 631081@bugs.debian.org

Subject: Re: Bug#631081: libpam-afs-session: logs aklog failures for cron jobs

Date: Sun, 19 Jun 2011 20:34:26 -0700

ucko@debian.org (Aaron M. Ucko) writes:
> Russ Allbery <rra@debian.org> writes:

>> Why is your crond running with KRB5CCNAME set in its environment?  I
>> suspect that at some point you restarted crond with a dirty environment,
>> probably from a user login....

> Good question; it looks like my (mostly default) sudo configuration
> leaks KRB5CCNAME, so a recent run of sudo aptitude safe-upgrade that
> resulted in restarting cron caused it to pick up my personal setting
> thereof. :-/  I'll adjust my setup to avoid that, but still feel it's
> enough of a gotcha that more widespread changes might be in order.

I agree with you, but I don't think it's pam-afs-session where the bug is.
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've seen debconf environment variables leaked into xinetd and then passed
along to subsequent user logins, which then breaks subsequent aptitude
runs.

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

Message #25 received at 631081@bugs.debian.org (full text, mbox, reply):

From: ucko@debian.org (Aaron M. Ucko)

To: Russ Allbery <rra@debian.org>

Cc: ucko@debian.org (Aaron M. Ucko), 631081@bugs.debian.org

Subject: Re: Bug#631081: libpam-afs-session: logs aklog failures for cron jobs

Date: Mon, 20 Jun 2011 11:40:04 -0400

Russ Allbery <rra@debian.org> writes:

> I agree with you, but I don't think it's pam-afs-session where the bug is.
> 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,

That's fair.  I can make a decent case for dpkg, and will reassign this
bug accordingly; please feel free to chime in post-reassignment if you
feel you have anything to add.

> I've seen debconf environment variables leaked into xinetd and then passed
> along to subsequent user logins, which then breaks subsequent aptitude
> runs.

I haven't hit that failure mode, but I did historically run into trouble
with my TEXMF setting causing TeX-related maintainer scripts to go
overboard (though it looks like sudo does at least filter that out
itself these days).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #30 received at 631081@bugs.debian.org (full text, mbox, reply):

From: ucko@debian.org (Aaron M. Ucko)

To: control@bugs.debian.org

Cc: 631081@bugs.debian.org

Subject: Bug#631081: dpkg: please clean environment for maintainer scripts

Date: Mon, 20 Jun 2011 11:55:02 -0400

retitle 631081 dpkg: please clean environment for maintainer scripts
reassign 631081 dpkg 1.16.0.3
thanks

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?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #43 received at 631081@bugs.debian.org (full text, mbox, reply):

From: "Witold Baryluk" <baryluk@smp.if.uj.edu.pl>

To: "Aaron M. Ucko" <ucko@debian.org>

Cc: 631081@bugs.debian.org

Subject: Re: Bug#631081: dpkg: please clean environment for maintainer scripts

Date: Mon, 20 Jun 2011 21:36:48 +0200

[Message part 1 (text/plain, inline)]

On 06-20 11:55, Aaron M. Ucko wrote:
> retitle 631081 dpkg: please clean environment for maintainer scripts
> reassign 631081 dpkg 1.16.0.3
> thanks
> 
> 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.

-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl

[signature.asc (application/pgp-signature, inline)]

Message #48 received at 631081@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Witold Baryluk <baryluk@smp.if.uj.edu.pl>, 631081@bugs.debian.org

Cc: "Aaron M. Ucko" <ucko@debian.org>, sysv-rc@packages.debian.org, rra@debian.org

Subject: Re: Bug#631081: dpkg: please clean environment for maintainer scripts

Date: Tue, 21 Jun 2011 08:50:43 +0200

On Mon, 20 Jun 2011, Witold Baryluk wrote:
> On 06-20 11:55, Aaron M. Ucko wrote:
> > retitle 631081 dpkg: please clean environment for maintainer scripts
> > reassign 631081 dpkg 1.16.0.3
> > thanks
> > 
> > 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.

Russ Allbery <rra@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.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #53 received at 631081@bugs.debian.org (full text, mbox, reply):

From: ucko@debian.org (Aaron M. Ucko)

To: Raphael Hertzog <hertzog@debian.org>

Cc: Witold Baryluk <baryluk@smp.if.uj.edu.pl>, 631081@bugs.debian.org, "Aaron M. Ucko" <ucko@debian.org>, sysv-rc@packages.debian.org, file-rc@packages.debian.org, rra@debian.org

Subject: Re: Bug#631081: dpkg: please clean environment for maintainer scripts

Date: Tue, 21 Jun 2011 11:58:32 -0400

Raphael Hertzog <hertzog@debian.org> writes:

> I think that cleaning the environment will create way more problems than
> what you expect.

Perhaps, though there's certainly room for discussion on how extensively
to clean, and even whether to use a whitelist or a blacklist.

> - for a start, the debconf UI might be pre-existing

Good point, I'd forgotten the d-i case, and likewise acknowledge that
some Debconf frontends use DISPLAY (and for that matter XAUTHORITY).

> - dropping http_proxy might break maintainer scripts calling wget

Right, that would be appropriate to keep too.

> - we obviously don't want to drop LANG and LC_*

Pas du tout! ;-)

> - respecting TMPDIR seems a good idea rather than a bad one

That's more debatable; private TMPDIRs may not be world-writable, which
could bite scripts that (directly or indirectly) launch processes as
non-root users.  (For that matter, root might not even be able to use
private TMPDIRs if they're on remote filesystems for some reason).

> I think it should be invoke-rc.d or something below this.

Perhaps both.  There are variables (DISPLAY and XAUTHORITY, for
instance) that are desirable to expose to maintainer scripts but not to
long-running services, but also some that I'd still argue neither should
see, including for instance the three initial examples of KRB5CCNAME,
TEXMF, and TMP(DIR).

BTW, the file-rc package ships an alternate invoke-rc.d implementation;
I've added its maintainers to the Cc: list.

> For dpkg, the only place where it might be helpful is start-stop-daemon.

I do agree that changing only s-s-d would be insufficient.

At any rate, thanks for the quick response!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #58 received at 631081@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 631081@bugs.debian.org

Cc: Witold Baryluk <baryluk@smp.if.uj.edu.pl>, "Aaron M. Ucko" <ucko@debian.org>, sysv-rc@packages.debian.org, rra@debian.org

Subject: Re: Bug#631081: dpkg: please clean environment for maintainer scripts

Date: Mon, 27 Jun 2011 01:00:06 +0200

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@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

Send a report that this bug log contains spam.