Bug#898949: schroot: PAM config should use common-session-noninteractive

2022-03-16 Thread Colin Watson
On Sun, Sep 08, 2019 at 10:41:52PM +0100, Roger Leigh wrote:
> On 07/09/2019 10:30, Simon McVittie wrote:
> > On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:
> > > On systems with libpam-systemd installed using common-session will
> > > create a logind session which schroot should not do.
> > In particular, creating a logind session results in $XDG_RUNTIME_DIR
> > being set inside the chroot, to a path that only exists outside the chroot.
> 
> Should this path be bound into the chroot?

It's hard to see how it's useful for schroot to create a logind session
on the host system at all.

> Which Debian version introduced common-session-noninteractive?

pam 1.0.1-11, which is sufficiently long ago (2009, well before
oldoldoldstable) that it no longer needs to be specified in
dependencies.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]



Bug#898949: schroot: PAM config should use common-session-noninteractive

2019-09-08 Thread Roger Leigh

On 07/09/2019 10:30, Simon McVittie wrote:


On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:

On systems with libpam-systemd installed using common-session will
create a logind session which schroot should not do.

In particular, creating a logind session results in $XDG_RUNTIME_DIR
being set inside the chroot, to a path that only exists outside the chroot.


Should this path be bound into the chroot?

Which Debian version introduced common-session-noninteractive?


Regards,

Roger



Bug#898949: schroot: PAM config should use common-session-noninteractive

2019-09-07 Thread Simon McVittie
On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:
> On systems with libpam-systemd installed using common-session will
> create a logind session which schroot should not do.

In particular, creating a logind session results in $XDG_RUNTIME_DIR
being set inside the chroot, to a path that only exists outside the chroot.

Packages that use $XDG_RUNTIME_DIR are expected to have some sort of
reasonable fallback behaviour if it is not set at all (for example
dbus disables the features that need it, and some other packages use
~/.cache/foo as a fallback version of $XDG_RUNTIME_DIR/foo), but they
often do not have a graceful fallback path if $XDG_RUNTIME_DIR is set
to a path that is inaccessible, on the basis that they should do their
best to obey explicit requests from the user/environment ("the user is
always right").

smcv