On Wed, 28 Aug 2002, Greywolf wrote:

> On Wed, 28 Aug 2002, Bill Studenmund wrote:
>
> # To be able to do PAM-style auth, we need to load auth modules into
> # binaries. To do some of the auth methods we want to do, we have to load
> # auth modules into binaries (like AFS auth, where you deal with tokens in
> # your process space). The reason we think it would be easy to start with
> # PAM is, well, because what PAM pruports to do is pretty much what we want.
>
> Pardon me if this doesn't seem particularly well thought-out on my part
> (probably because it isn't), but:
>
> Why can there not be a message-pass going on between the binary and
> a run-alone authenticator?
>
> (I think I already know the answer to this, but I needed to ask anyway.)
>
> ["You can't do that because 1) there's no guarantee that the run-alone
> authenticator will be running when you're going into single-user mode
> demanding access at the console by way of a method that init's not
> prepared to handle and 2) because if the binary itself doesn't know the
> ABI, it can't pass things out to the program that it's expecting -- for
> that to work, you need to recompile the binary in question, or a library
> that it references, so we're back to where we are now; and 3) implementing
> said authenticator, by the arguments you've already made in the parent
> thread regarding adding complexity, represents YAPOF."
>
> please correct me if I'm wrong. ]

No, you got it exactly right. Well, 2) is the key one in my mind. 1) is a
problem, but if it were a big-enough one, we could work around it. 2),
though, we can't get around. Yes, we could do something like 3), where we
have loadable modules that know the message protocol, and you only have to
load the module. It might work out that's easier, but we have to be able
to load the module anyway to get there. :-)

It could be that once we have the ability to add modules, that folks will
make modules that speak their MPI and leave the guts of the authentication
to a daemon. That might be a good design choice. But we need the ability
to load those modules first. :-)

> # This doesn't mean we plan on repeating the mistakes we think other PAM
> # implementations make.
>
> Is there a way that we could sanely implement, say, an order of things,
> with a default fallback so that if PAM pukes -- as it has been reknowned
> to do on occasion -- we're not hosed trying to get PAM to pick up the
> pieces?

Don't know yet. While we have ideas on what we want to do, we haven't
started coding yet.

> Will there be a way that we can specify that we don't even want to
> bother with PAM at all, and just use BSD-Auth?

I'd assume so. nsswitch will have to be configured to use PAM (and
bsd-auth), so my no-code-written assumption is that yes, you will be able
to.

> # > It seems pretty clear that all these arguments for PAM are based on
> # > misinformation and false assumptions.
> #
> # Is it that, or that you heard some of what folks wanted to do and
> # projected thoughts onto that that they didn't say?
>
> I'm not arguing in favour of either party here, but you must admit that
> when people leave things out of the picture, it does leave a lot of room
> for concern, and that's only an observation from experience, both as
> the person who's had to deal with missing information, and as someone
> who has intentionally left out information for just such an emergency.

The problem though is that we aren't saying, "here's the PAM or BSD-auth
or whatever frameowrk I plan on committing," we're at the stage of saying,
"this is the direction we want to go." The details you elude to above
haven't been set, so how can we reasonably talk about them? I'm not saying
they are unimportant. I'm saying now is not the time to argue them. Maybe
express them as concerns to they are kept in mind.

This general theme has played out via many actors on many of the lists,
and really hurts the project. Folks get worried about implementation
details (perhaps very valid ones), and end up arguing against direciton
choices rather than helping do a given direction right. The main effect is
to actually make folks NOT write code, so we get nowhere. :-(

Take care,

Bill