On Sat, 06 Sep 2003 17:49:26 -0500, Peter Seebach writes:
>In message <20030906221953.D20BEA630@zen.crufty.net>, Simon J. Gerraty writes:
>>An early proposal was to do a shim API, but that got shot down but the
>>"I only want BSD Auth" gallery.
>
>No, it got shot down by the impossibility of any kind of reasonably clean
>API which handles both BSD Auth and PAM.

Yes, and the fact that a subset or superset api wasn't deemed
appropriate as I recall?

>>Another option was do BSD Auth via PAM - also shot down by the 
>>"I only want BSD Auth" gallery.  
>
>No, it got shot down by the lack of API compatibility; if I can't compile
>a program which uses BSD Auth, then I don't have BSD Auth.

No... I was talking about how NetBSD's login etc would use this.  If
you want to build say OpenBSD's login, ftpd or anything else that uses
BSD Auth and link it against a libbsdauth or something, that should
work no?  That's a real question not a retorical one - I don't claim
to know enough about BSD Auth to say for sure.

As I mentioned before, I think it would be cool to have a libbsdauth
(and a libpam) - so that apps that expect to use those api's
directly/fully "just can".  Our implementation of those libs will
likely need to deal with nsswitch etc, but I'd hope that that level of
functionality should be easy to provide.

But, I wasn't talking about apps that use BSD Auth or even PAM right
now.  I'm talking about NetBSD's login, su, sshd etc.  Ideally those
should work with either - hence the desire for a shim or one api in
terms of the other.  

>I don't object to PAM existing, or being in the system, but I want to be able
>to compile a program which uses BSD Auth and have it work.

I'd like for you to have that too.  But not necessarily at the expense
of me _having_ to use it too, or at the cost of login et al looking like
a dog's breakfast.

>I think the "only BSD Auth" gallery is a figment of your imagination.

Perhaps "PAM - not on my system - no way" gallery might be more accurate.
I'm not refering to you in that term btw - your contributions to this
thread have been the most helpful and constructive of any of the BSD
Auth advocates - thanks.

>I think the best solution available to us is:
>1.  Implement libbsdauth and libpam.

Agreed.

>2.  Build calls for both of them into login/su/xdm/etc.  This is mostly
>already done if we're willing to steal code from two different systems.

That's what I'd like to avoid.

>3.  Optionally, implement a new API which handles the easy cases and
>switches between them.

That I think is/was the long term goal.

>Neither API is a proper subset of the other.

So it would seem - which is why any solution other than your #2 above,
will necessarily be a compromise.

Of course there's also

0. Find some poor bunny with enough time/energy/flame retardant
   to volunteer to do this - and do so in a manner that will get the
   Ok to commit. 

Doing this right is more than a couple of afternoon's work (even if
the coding is easy, the flamage side can sap all your
time/energy/enthusiasm) and I for one lack the time.

Thanks
--sjg