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

[Martin Schlemmer <azarah@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]