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
signature.asc
Description: This is a digitally signed message part
