Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Simon Richter]

Hi,

On 18.09.23 05:16, Julian Andres Klode wrote:


If you follow the argument for /usr to its logical conclusion of being
the complete image, you end up moving state of the image (as opposed to
the system) from /var/lib to /usr as well, for example /var/lib/dpkg and
/var/lib/apt/extended_states.


The way I understood it, images cannot be updated. Instead, users will 
build or receive a new image, and quickly "reboot" into that by having 
running services transfer their state over to new instances.


   Simon

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Julian Andres Klode]

On Fri, Sep 15, 2023 at 04:05:50PM -0700, Steve Langasek wrote:
> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> > With the provision that I know next to nothing about pam - if I
> > understood correctly how it works, why not simply do both? Ship the
> > default file in the package under both /usr and /etc. Then, you get
> > the semantics you want with local changes tracking, and /etc wins over
> > the defaults. And we can have a working, bootable Debian container
> > with only /usr. As far as I've been told, pam is the only blocker
> > there - for a minimal image of course, but that's still quite a good
> > achievement. Wouldn't this work, or am I missing something?
> 
> While I have applications downstream which also care about empty /etc, the
> current situation is that this wouldn't help because almost all the
> PAM application configs in Debian reference one or more of
> common-{account,auth,password,session,session-noninteractive} which are
> constructed at package install time and therefore are inappropriate to ship
> in /usr.

I do not believe the files being constructed at install time makes them
inappropriate to ship in /usr, We have precedence for doing that, 
compiled bytecode for python is essentially the same case.

If you follow the argument for /usr to its logical conclusion of being
the complete image, you end up moving state of the image (as opposed to
the system) from /var/lib to /usr as well, for example /var/lib/dpkg and
/var/lib/apt/extended_states.

To my knowledge, similar changes are already implemented in higher
paced distributions.

Potentially there should be a /usr/var to encapsulate image state
as opposed to image data but that's somewhat bikeshedding.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Marco d'Itri]

On Sep 16, Steve Langasek  wrote:

> While I have applications downstream which also care about empty /etc, the
> current situation is that this wouldn't help because almost all the
> PAM application configs in Debian reference one or more of
> common-{account,auth,password,session,session-noninteractive} which are
> constructed at package install time and therefore are inappropriate to ship
> in /usr.
Actually it would still help a lot, because pam-auth-update can be run 
on the first boot to rebuild the /etc/pam.d/*common-* files.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Marco d'Itri]

On Sep 16, Russ Allbery  wrote:

> However, and this is very important, *no one has decided that you get to
> do that work in Debian*.
I am confident that I have never said otherwise.

> Right now, any base system package maintainer could decide that putting
> configuration files in /etc makes sense for reasons of their own limited
> to their specific package and further break support for booting a system
> in this mode, and there are no grounds to ask them not to do this.
> Because you don't have an *agreement*.
I think that I am allowed to ask all I want at any time (severity: 
wishlist), but they can also choose to not care.

> Accomplishing things like this in Debian has a large social component that
> I think is being neglected.
After having initiated a few things like this in Debian I suspect that 
I am beginning to understand why this may happen.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Russ Allbery]

Marco d'Itri  writes:
> On Sep 15, Sam Hartman  wrote:

>> I have significant discomfort aligning what you say (pam is the last
>> blocker) with what several people said earlier in the week.  What I
>> heard is that there was no project consensus to do this, and that
>> people were running experiments to see what is possible.

> Indeed. I did the experiments and they where unexpectedly positive:  pam
> is the only blocker for booting _the base system_.

> I never expected that everything would immediately work just fine with
> an empty /etc: my goal is to have support for this in the base system
> and selected packages.

This started as an experiment: you were going to try running the base
system in this mode with existing packages and see what happens.  You ran
that experiment and got results: it doesn't work, but it appears to only
work because of PAM.  So far, so good.  You ran an experiment, the result
was that the thing you want to do doesn't work, and now you understand
what changes would be required to move forward.

However, and this is very important, *no one has decided that you get to
do that work in Debian*.

Insofar as this is just a personal goal, sure, that's none of the business
of anyone else.  But if you want this to be a *project* goal, you're
skipping a few important steps.

The biggest ones is that there is no *plan* and no *agreement*.  By plan,
I mean an actual document spelling out in detail, not email messages with
a few sentences about something that is familiar to you but not to other
people who haven't been thinking about this, what base system support
would look like.  And by agreement, I mean that the maintainers of base
system components agree that this is something that we are working towards
as a project and something that they would not break lightly.

Right now, any base system package maintainer could decide that putting
configuration files in /etc makes sense for reasons of their own limited
to their specific package and further break support for booting a system
in this mode, and there are no grounds to ask them not to do this.
Because you don't have an *agreement*.

I feel like there is a tendency to consider work on Debian to be purely
technical.  If you turn it on and smoke doesn't come out, it works, so we
have implemented that thing, and the goal is accomplished.  This doesn't
work, precisely because other people break your goal later (because they
were never asked or never agreed with that goal), and then they are very
confused about why you're upset and why your problems are now their
problems.  Or, worse, their packages are broken as collateral damage in
accomplishing some goal, and you then argue that it's their problem to fix
their packages, even though there was no agreement about that goal.

Accomplishing things like this in Debian has a large social component that
I think is being neglected.

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

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Luca Boccassi]

On Sat, 16 Sept 2023 at 11:20, Matthew Garrett  wrote:
>
> On Fri, Sep 15, 2023 at 02:08:06PM -0600, Sam Hartman wrote:
> >
> >
> > Apropos of the discussion about removing default configuration from
> > /etc.
> > Upstream PAM now supports doing that.  You can set up a vendor directory
> > such as /usr/lib where pam.d and security live.
>
> What are other distributions doing here?

I have been told by an upstream PAM maintainer, and by
Fedora/Suse/Arch folks at the image-based linux summit this week that
this is not an issue in their respective distros, and that the way
they ship the default PAM configuration works using only /usr.

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:
>>> "Peter" == Peter Pentchev  writes:

Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter> that the distribution ships in /etc, trying to make sure that
Peter> some specific service could never possibly succeed if it
Peter> should ever attempt PAM authentication? Then, if there is a
Peter> default shipped in /usr, the service authentication attempts
Peter> may suddenly start succeeding when the PAM packages are
Peter> upgraded on an existing system.

>> This might be an issue in general, but it is not an issue for
>> PAM.  PAM falls back on the other service if a service
>> configuration cannot be found.

Russ> I think that makes it an even more subtle problem, doesn't it?

Russ> Currently, my understanding is that if I delete
Russ> /etc/pam.d/lightdm, PAM falls back on /etc/pam.d/other.  But
Russ> if we define a search path for PAM configuration such that it
Russ> first looks in /etc/pam.d and then in /usr/lib/pam.d, and I
Russ> delete /etc/pam.d/lightdm, wouldn't PAM then fall back on
Russ> /usr/lib/pam.d/lightdm and not /etc/pam.d/other?  Unlike
Russ> Peter's example, that would be a silent error; authentication
Russ> may well succeed, but without running, say, pam_limits.so.


Yes, thanks for pointing this out.

--Sam

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Matthew Garrett]

On Fri, Sep 15, 2023 at 02:08:06PM -0600, Sam Hartman wrote:
> 
> 
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that.  You can set up a vendor directory
> such as /usr/lib where pam.d and security live.

What are other distributions doing here?

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Steve Langasek]

On Fri, Sep 15, 2023 at 03:17:42PM -0600, Sam Hartman wrote:
> Luca> And we can have a
> Luca> working, bootable Debian container with only /usr.

> I'm not actually convinced this is a good thing.
> (I don't think it's a bad thing--I just am not convinced it's something
> we should be working toward).
> I'd rather see project level discussion of this and a decision that is
> something we want.

> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the week.
> What I heard is that there was no project consensus to do this, and that
> people were running experiments to see what is possible.

> If I make a change in pam and we're suddenly at a place where  there are
> no blockers and we're moving forward, I think people in the project
> would understandably feel disenfranchised.
> To bystanders, "we're running experiments to see what's possible," means
> a decision is far off.

I agree with you that these sorts of changes should be discussed openly in
debian-devel, and plans talked about, before we get too far down the path.
Just as I advocated for when it came to DPKG_ROOT support in base packages.
I do not want to see the fact that maintainers of base packages have
individually decided it's worthwhile to support a thing, to be used to
strong-arm other maintainers into feeling they also have to support a thing
for which there may be no consensus.

However, I do not think that *reaching* a consensus about this being a good
thing needs to be a blocker for maintainers deciding to support it.  As
pointed out, there is nothing in Policy requiring any package to ship any
files in /etc, it's only required that if a user wants to change the
defaults for a package they should be able to do so via /etc (or /var).  If
it happens that all maintainers of base packages believe they can
satisfactorily meet the needs of their users to configure those packages
without shipping any default configs in /etc, those maintainers are free to
make such changes to support this, without waiting for project consensus.

Doing so doesn't penalize existing users and use cases of Debian (unless
the maintainer is wrong about meeting users' needs, or makes a hash of the
upgrade handling).  And it would allow Debian to be used in contexts where
it can't be today.  It's basically a win-win.

> I feel like if I were to fall in on this, I might be helping cause
> something to happen  at a technical level, bypassing discussion that I
> believe would be healthy for the project.
> I appreciate the value of doing work and  having people who  are willing
> to do the work have a larger share of power in the decision making.

I would like to see that discussion happen.  I don't think this thread is
that discussion, and I'm not stepping forward to drive it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Marco d'Itri]

On Sep 15, Sam Hartman  wrote:

> But for the most part PAM appears to just override on a file-by-file
> basis.
Just like udev, kmod, dbus, etc...
PAM is not different.

> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the week.
> What I heard is that there was no project consensus to do this, and that
> people were running experiments to see what is possible.
Indeed. I did the experiments and they where unexpectedly positive:
pam is the only blocker for booting _the base system_.
I never expected that everything would immediately work just fine with 
an empty /etc: my goal is to have support for this in the base system 
and selected packages.

See for yourself:

mkdir /var/lib/machines/empty/
ln -s usr/bin usr/sbin usr/lib usr/lib64 /var/lib/machines/empty/
# this is a workaround for PAM
mkdir /var/lib/machines/empty/etc/
cp -a /etc/pam.d /etc/security /var/lib/machines/empty/etc/
# this is a workaround for https://github.com/systemd/systemd/issues/29185
echo ID=unknown > /var/lib/machines/empty/etc/os-release

systemd-nspawn --private-network --network-veth -b \
  --bind-ro=/usr --tmpfs=/var/ --tmpfs=/tmp/ \
  -D /var/lib/machines/empty/

You could add --tmpfs=/etc/ too, but then logins would fail.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Steve Langasek]

On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> With the provision that I know next to nothing about pam - if I
> understood correctly how it works, why not simply do both? Ship the
> default file in the package under both /usr and /etc. Then, you get
> the semantics you want with local changes tracking, and /etc wins over
> the defaults. And we can have a working, bootable Debian container
> with only /usr. As far as I've been told, pam is the only blocker
> there - for a minimal image of course, but that's still quite a good
> achievement. Wouldn't this work, or am I missing something?

While I have applications downstream which also care about empty /etc, the
current situation is that this wouldn't help because almost all the
PAM application configs in Debian reference one or more of
common-{account,auth,password,session,session-noninteractive} which are
constructed at package install time and therefore are inappropriate to ship
in /usr.

Shipping the same file in both /usr and /etc from application packages seems
like it would be a reasonable workaround as far as it goes, but doesn't let
us empty /etc/pam.d.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Russ Allbery]

Sam Hartman  writes:
>> "Peter" == Peter Pentchev  writes:

> Peter> Hm, what happens if a sysadmin deliberately removed a file
> Peter> that the distribution ships in /etc, trying to make sure that
> Peter> some specific service could never possibly succeed if it
> Peter> should ever attempt PAM authentication? Then, if there is a
> Peter> default shipped in /usr, the service authentication attempts
> Peter> may suddenly start succeeding when the PAM packages are
> Peter> upgraded on an existing system.

> This might be an issue in general, but it is not an issue for PAM.  PAM
> falls back on the other service if a service configuration cannot be
> found.

I think that makes it an even more subtle problem, doesn't it?

Currently, my understanding is that if I delete /etc/pam.d/lightdm, PAM
falls back on /etc/pam.d/other.  But if we define a search path for PAM
configuration such that it first looks in /etc/pam.d and then in
/usr/lib/pam.d, and I delete /etc/pam.d/lightdm, wouldn't PAM then fall
back on /usr/lib/pam.d/lightdm and not /etc/pam.d/other?  Unlike Peter's
example, that would be a silent error; authentication may well succeed,
but without running, say, pam_limits.so.

I don't know if anyone is making this specific configuration change, but
if they are, I think that result would be surprising.

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

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

> "Peter" == Peter Pentchev  writes:

Peter> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
>> On Fri, 15 Sept 2023 at 21:08, Sam Hartman  wrote:

Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter> that the distribution ships in /etc, trying to make sure that
Peter> some specific service could never possibly succeed if it
Peter> should ever attempt PAM authentication? Then, if there is a
Peter> default shipped in /usr, the service authentication attempts
Peter> may suddenly start succeeding when the PAM packages are
Peter> upgraded on an existing system.

This might be an issue in general, but it is not an issue for PAM.
PAM falls back on the other service if a service configuration cannot be
found.

--Sam

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> With the provision that I know next to nothing about pam - if
Luca> I understood correctly how it works, why not simply do both?
Luca> Ship the default file in the package under both /usr and
Luca> /etc. Then, you get the semantics you want with local changes
Luca> tracking, and /etc wins over the defaults.

I honestly had not considered this.
It's a bit more tricky than you imply because it's not just pam that is
involved with this but also all pam applications.

We'd have to do active work to get every pam application to ship in both
places.

But as I said I had not considered this, and so it's something that I'm
open to thinking more about.


Luca> And we can have a
Luca> working, bootable Debian container with only /usr.

I'm not actually convinced this is a good thing.
(I don't think it's a bad thing--I just am not convinced it's something
we should be working toward).
I'd rather see project level discussion of this and a decision that is
something we want.

I have significant discomfort aligning what you say (pam is the last
blocker) with what several people said earlier in the week.
What I heard is that there was no project consensus to do this, and that
people were running experiments to see what is possible.

If I make a change in pam and we're suddenly at a place where  there are
no blockers and we're moving forward, I think people in the project
would understandably feel disenfranchised.
To bystanders, "we're running experiments to see what's possible," means
a decision is far off.


I feel like if I were to fall in on this, I might be helping cause
something to happen  at a technical level, bypassing discussion that I
believe would be healthy for the project.
I appreciate the value of doing work and  having people who  are willing
to do the work have a larger share of power in the decision making.

And yet I feel like especially for project level things, it's valuable
to present an idea, give people an opportunity to start working on
alternatives, give people an opportunity for their objections to be
heard, and see where we are *before* it's all but done technically.
I think we've not done such a great job of the above in the past.  Oh,
we've had the discussions and the flame wars, but I think our past
discussions have had a number of problems in common:

* Because things were effectively close to done technically in the minds
  of those driving the change, they had a degree of power that made
  others feel disadvantaged and defensive in the discussions.

* Sometimes when people have raised objections, they haven't understood
  the goals of people driving change.  So while their objections might
  in principle be valid, they were not actionable because they didn't
  understand what the goals were.  We've done a bad job of bringing
  those people into the discussion.  Doing better would probably be part
  clearly articulating why the proposed fix doesn't meet the goals, and
  clearly articulating that if the person with the objection will do the
  work to understand the goal, then the rest of us will do the work to
  bring them into the discussions.

* We have sometimes not done a job of giving people a chance to build
  alternatives--somehow saying that we've gotten to a place where there
  is interest in some particular goal, and it's serious enough that
  people need to either fall in on the plan that currently has momentum
  or quickly start putting energy into alternatives.  Finding the point
  for this is tricky; it's important that if people really are motivated
  to find another solution they still have time to do so, but it's also
  important to realize that people may not focus on something until they
  see that an approach they do not like has momentum.  ( Init systems
  are not an example where I think we had this problem; people knew that
  decision was coming and had a chance to explore alternatives.)

* Sometimes people have walked away from our discussions confused about
  the outcome or feeling like their opinion/input was not considered.
  We've actually be improving significantly on this lately.  I think the
  recent usrmerge discussions (say last two years) have been much better
  than earlier discussions at  considering input and making it clear
  where the discussion ended up.
  


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Peter Pentchev]

On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> On Fri, 15 Sept 2023 at 21:08, Sam Hartman  wrote:
> >
> >
> >
> > Apropos of the discussion about removing default configuration from
> > /etc.
> > Upstream PAM now supports doing that.  You can set up a vendor directory
> > such as /usr/lib where pam.d and security live.
> >
> > I thought about doing that for Debian PAM, and have decided against.
> > My rationale is that I actually think dpkg gives superior handling of
> > upstream configuration changes to what we'd get with the pam vendor dir
> > *in the specific case of PAM*.
> >
> > In particular, dpkg will let you know if the conf file has changed
> > upstream and you have local changes.
> > If we create a vendor directory,  you will have to diff yourself to
> > discover that.
> >
> > I do think that in the case of programs like systemd that do a complex
> > merge of drop in fragments, the split of vendor dir from sysadmin dir
> > makes a lot of sense.
> >
> > But for the most part PAM appears to just override on a file-by-file
> > basis.
> > And for that use case, I think dpkg's handling is at least as good.
> > I appreciate others might differ.  With dpkg's conffile handling you get
> > better notification of changes but is it is hard to see at a glance
> > which files might be changed.
> >
> > I am in favor of having a mechanism to easily reset the state in /etc.
> > Personally I'm not convinced that deleting /etc is the best way for
> > Debian to do that.
> > I think we might be able to find dpkg-based solutions that are superior.
> >
> > If Debian  does develop a project consensus behind  minimizing
> > /etc--especially if there is a policy recommendation or encouragement in
> > this direction, then I'll revisit how we handle this for PAM.
> >
> > If Debian develops another approach for resetting local state, I'll be
> > eager to look at that for PAM.
> 
> With the provision that I know next to nothing about pam - if I
> understood correctly how it works, why not simply do both? Ship the
> default file in the package under both /usr and /etc. Then, you get
> the semantics you want with local changes tracking, and /etc wins over
> the defaults. And we can have a working, bootable Debian container
> with only /usr. As far as I've been told, pam is the only blocker
> there - for a minimal image of course, but that's still quite a good
> achievement. Wouldn't this work, or am I missing something?

Hm, what happens if a sysadmin deliberately removed a file that
the distribution ships in /etc, trying to make sure that some specific
service could never possibly succeed if it should ever attempt
PAM authentication? Then, if there is a default shipped in /usr,
the service authentication attempts may suddenly start succeeding
when the PAM packages are upgraded on an existing system.

Yes, I know that the override/drop-in mechanism provides a way to
do that by creating a /dev/null override symlink, but the sysadmin
would not have needed to do that - until now, when they suddenly do.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Luca Boccassi]

On Fri, 15 Sept 2023 at 21:08, Sam Hartman  wrote:
>
>
>
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that.  You can set up a vendor directory
> such as /usr/lib where pam.d and security live.
>
> I thought about doing that for Debian PAM, and have decided against.
> My rationale is that I actually think dpkg gives superior handling of
> upstream configuration changes to what we'd get with the pam vendor dir
> *in the specific case of PAM*.
>
> In particular, dpkg will let you know if the conf file has changed
> upstream and you have local changes.
> If we create a vendor directory,  you will have to diff yourself to
> discover that.
>
> I do think that in the case of programs like systemd that do a complex
> merge of drop in fragments, the split of vendor dir from sysadmin dir
> makes a lot of sense.
>
> But for the most part PAM appears to just override on a file-by-file
> basis.
> And for that use case, I think dpkg's handling is at least as good.
> I appreciate others might differ.  With dpkg's conffile handling you get
> better notification of changes but is it is hard to see at a glance
> which files might be changed.
>
> I am in favor of having a mechanism to easily reset the state in /etc.
> Personally I'm not convinced that deleting /etc is the best way for
> Debian to do that.
> I think we might be able to find dpkg-based solutions that are superior.
>
> If Debian  does develop a project consensus behind  minimizing
> /etc--especially if there is a policy recommendation or encouragement in
> this direction, then I'll revisit how we handle this for PAM.
>
> If Debian develops another approach for resetting local state, I'll be
> eager to look at that for PAM.

With the provision that I know next to nothing about pam - if I
understood correctly how it works, why not simply do both? Ship the
default file in the package under both /usr and /etc. Then, you get
the semantics you want with local changes tracking, and /etc wins over
the defaults. And we can have a working, bootable Debian container
with only /usr. As far as I've been told, pam is the only blocker
there - for a minimal image of course, but that's still quite a good
achievement. Wouldn't this work, or am I missing something?

Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

Apropos of the discussion about removing default configuration from
/etc.
Upstream PAM now supports doing that.  You can set up a vendor directory
such as /usr/lib where pam.d and security live.

I thought about doing that for Debian PAM, and have decided against.
My rationale is that I actually think dpkg gives superior handling of
upstream configuration changes to what we'd get with the pam vendor dir
*in the specific case of PAM*.

In particular, dpkg will let you know if the conf file has changed
upstream and you have local changes.
If we create a vendor directory,  you will have to diff yourself to
discover that.

I do think that in the case of programs like systemd that do a complex
merge of drop in fragments, the split of vendor dir from sysadmin dir
makes a lot of sense.

But for the most part PAM appears to just override on a file-by-file
basis.
And for that use case, I think dpkg's handling is at least as good.
I appreciate others might differ.  With dpkg's conffile handling you get
better notification of changes but is it is hard to see at a glance
which files might be changed.

I am in favor of having a mechanism to easily reset the state in /etc.
Personally I'm not convinced that deleting /etc is the best way for
Debian to do that.
I think we might be able to find dpkg-based solutions that are superior.

If Debian  does develop a project consensus behind  minimizing
/etc--especially if there is a policy recommendation or encouragement in
this direction, then I'll revisit how we handle this for PAM.

If Debian develops another approach for resetting local state, I'll be
eager to look at that for PAM.

--Sam


signature.asc
Description: PGP signature