List:Internals« Previous MessageNext Message »
From:Sergei Golubchik Date:June 2 2008 5:28pm
Subject:Re: Students, start your engines...
View as plain text  

I'm cc to internals@ please keep technical discussions on the list.

On Jun 02, Milos Prodanovic wrote:
> >
> > Isn't that true for PAM too ? It's not a protocol on itself, it
> > requires an application to provide a conversation function that will
> > allow pam module to communicate over whatever protocol application
> > supports.  So, you can say that PAM is a layer in any protocol too.
> >
> > Of course, you can say that we won't support conversation function
> > in the first version - in that case PAM won't be a layer in mysql
> > client-server protocol. But in that case adding support for SASL
> > without conversation is just as simple, I assume.
> >
> PAM is not protocol too, I agree, but PAM is module and SASL is not. I
> was thinking that you wanted SASL as inside mysql protocol. SASL can
> be module for authentication if you refer to some exact SASL
> implementation in some exact protocol.

PAM isn't a module, it's a framework. There's a library that
applications use. And there're modules for specific authentication

SASL is similar, but it calls its plugins "mechanisms" not "modules".
> One can't put PAM in protocol, since it's module, you can only
> authenticate someone with following PAM framework.

Oh, one certainly can. That's what conversation callback is for.
And look in your /etc/pam.d/ - there're files like cups, imap, pop3,
rsh - one can use PAM over the protocol.

> > Anyway, my vision was not to have PAM support in MYSQL, but our own
> > implementation of authentication plugins. And support PAM as "pam
> > authentication plugin for MySQL" - that is a plugin that, basically,
> > maps PAM to our authentication API. Same for SASL. Same for SSL.
> >
> Yes that's my vision too. PAM inside module of moduler auth interface.
> Well SASL is not same, since SASL have many implementations, and only
> SMTP is RFC-ed, so since SASL is layer, and if we want to support it
> in module as a plugin, we have to decide on what exact SASL protocol
> we will provide support.

No, we - I mean MySQL server core - won't provide support for any SASL
protocol or for PAM. Only for our own API. SASL and PAM will be
supported by mapping plugins. We only need to make sure that it's
possible to write these plugins, that is, that our API is not more
restricting or limiting that PAM or SASL.

That's what I meant here:

> > And the main challenge, as I see it, is to create an API that is
> > generic enough so that both PAM and SASL could be supported in these
> > mapping plugins.
> >
> That's right, but SASL as a layer have some more nice features, and
> I'll try to explore more on those.
> Still maybe I'm missing point, for now one can authenticate using SASL
> only on some SMTP or cirus imap4/pop3 implementation. Small number of
> users are kept authenticating on smtp/imap/pop.

Yes, there are not many projects using SASL, but check this:
> From my point of view there is more need for implementing  LDAP or
> RADIUS then SASL but still we can do it. I've looked some apache sasl
> modules and they are easy to implement, still I wouldn't know on what
> will I authenticate when I build SASL module, but I'll find that out -
> it's nice to learn new technologies.

No, there's no need to build SASL module :)

Again - we only need to make sure that it's possible to build it, to
build a module that allows MySQL to use SASL mechanisms (to the extent
possible without conversation, if you don't want to implement it).

> Both SASL and PAM authenticate on username/password, all other
> features in PAM/SASL/RADIUS/LDAP are optional (such as realm, suffix,
> prefix, dn) and those are in my opinion implemented inside plugin
> module not in modular authentication interface ?


> Do you have some example scenario where something more than
> username/password could be needed for MySQL authentication ?

S/key, for example.

> As I understand we have to module as remote readonly authentication ?
> (we do not support password change if authentication is not local)

Yes, let's not bother with password changes. Not in this project, at
Regards / Mit vielen Grüssen,

   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Häring
Modifying permissions in memoryMatt Barringer17 Nov
Re: Students, start your engines...Sergei Golubchik2 Jun