In message <20030907005321.2BF8D690C@void.crufty.net>, "Simon J. Gerraty" write
s:
>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?

I don't think it matters; we simply can't make any reasonably plausible API
which handles both cases, because their models are so different.  I don't
think we can abstract away to a "common model".

>>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?

The thing is, these turn out to be very closely related; if we're going to
have a libbsdauth at all, we might as well use the existing, trivial, patches
for login/ftpd/etc.

>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.

That sounds good to me.

>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 think either can be done in terms of the other; each has features
the other can't implement, so a mod_bsdauth.so for PAM wouldn't let you do
everything that libbsdauth and a program which supported it would do, and
vice versa for /usr/libexec/login_pam.

>>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 we're stuck with login coming out looking like a dog's breakfast.

>>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.

I'm not sure we can.  I think login is stuck knowing about multiple auth
methods.

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

>That I think is/was the long term goal.

But it'll only work for the *EASY* cases, and that means that interesting
auth modules - the ones that people are pointing to as "why I need PAM" or
"why I need BSD Auth" - will *fail entirely* with this API.

Which is bad.

>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.

Understood.  The problem here is that this might well be one of the only
cases where there's a real reason to have a feature of /bin/login *totally
removed* in some builds.  I think it's reasonable for people on both sides
to say "I do not want ANY code for the other auth system even in /bin/login",
because we all (I hope!) agree that it's reasonable for people not to want
extra code they won't be using in the system's auth code.  It's just one
more point of exposure to bugs.

So, we may end up wanting
	#if defined(BSD_AUTH) && defined(PAM_AUTH)
		/* nssswitch-style code */
	#else if defined(BSD_AUTH)
		/* call BSD auth */
	#else if defined(PAM_AUTH)
		/* call PAM */
	#else
		/* just grovel in spwd.db */
	#endif

Not because it's the cleanest, or the best, but because it's the best we can
do.

-s