Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Martin Schlemmer]

On Wed, 2005-03-30 at 22:15 +0200, Diego "Flameeyes" Pettenò wrote:
> Ok, second part of my odyssey in PAM implementations.
> After a day searching for example config files and so on, I found out that
> Linux-PAM already support the include syntax of openpam since version 0.78.
> This is useful to our needs, because it allow us to have a single
> configuration file which works on both openpam and linux-pam.
>
> The old syntax is that:
>
> class required pam_stack.so service=system-auth
>
> the new one should be:
>
> class include system-auth
>

Right, like I said this is the better idea in previous post (replied
before reading this one).

> Now, to start making the changes needed to have complete openpam/linuxpam
> intercompatibility, there's need of a few changes in tree:
> - we need a virtual/pam, which could be provided by linux-pam or by openpam;

Right.  It should be profile specific I guess, as I am not sure we want
it on linux boxes to keep things simple.

> - we need an ebuild for openpam (i've wrote one, but still misses a few
> points, mainly for the missing thigns here stated)

And you/bsd_peeps will obviously maintain it.

> - we need a virtual/pam-modules which could be provided by linux-pam or by a
> new freebsd-pam-modules (they work also under linux as far as I know... i'll
> test that better when I'll have the other things working, now is a bit
> complicated to do), openpam will pdepend on freebsd-pam-modules to provide
> both in a simple way.

Why?  What good will they do on linux?  Just stick them in bsd profile.

> - not needed, but surely helpful, sys-libs/pam could be renamed to
> sys-libs/linux-pam, or sys-libs/Linux-PAM which is it's exact spelling. This
> way we have a consistent naming scheme

Like I said before, only real reason why I will biatch about this one,
is its called 'pam' on all linux distro's, and it will be another lost
history (ok, so the workaround is a schlepp) case without real cause.

> - all the dependency on sys-libs/pam should be changed to virtual/pam (also if
> they use pam_stack.so under openpam, until we have fixed everything this
> could be worked around by the ones using openpam... initially only
> experimental users should use it, so they should be able to cope with broken
> configuration files, see next point for solution)

Well, the first thing will be more testing to get Linux-PAM-0.78 stable,
and then go through the tree - think that will be more the deciding
factor than bsd (who cares about bsd anyhow :P).

> - the new ebuilds should add a new configuration file with the new syntax, and
> should depend on: || ( >=sys-libs/pam-0.78 virtual/pam ). This would fix the
> previous point, as who is using openpam will use the ~arch packages which
> will be fixed one by one (by me, submitting patches to maintainers), this way
> the packages will work out-of-the-box for both g/linux and g/fbsd users (i
> haven't searched on macosx, but should be, as they have the same userlands of
> fbsd).
>

Ugh, no - just more crud that somebody will have to clean out later.
Like I said, get pam-0.78 and issues fixed, bumped to stable on all
linux archs, and we can scourge the tree.

> I'll work anyway on a pam_stack hack for openpam, also if I'm not sure if,
> when and how I'll be able to make it work... also I don't like too much
> messing with security stuff :/
>

Sorry, you are on your own here.

> Well.. if there's someone (lu_zero? :) ) which doesn't like this solution...
> comments accepted :)
>


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa