maria-developers team mailing list archive
Mailing list archive
Re: win auth plugin
On Dec 30, Vladislav Vaintroub wrote:
> > -----Original Message-----
> > From: sergii@xxxxxxxxx [mailto:sergii@xxxxxxxxx]
> > Sent: Freitag, 30. Dezember 2011 21:03
> > To: wlad@xxxxxxxxxxxxxxxx
> > Cc: maria-developers@xxxxxxxxxxxxxxxxxxx
> > Subject: win auth plugin
> > Attached is the patch for the windows authentication plugin.
> > To avoid code duplication I've reused MySQL's windows authentication
> > plugin and only wrote the server part.
> > This plugin is different from MySQL's, because (as all our plugins)
> > it does not do user name mapping and only preforms the
> > authentication - that is, only verifies that the user really is who
> > he says he is.
> Hmm:) Supplying user name and verifying is sort of duplicating
> information. Server knows exactly who's connecting anyway, after the
> handshake is performed. So - is that providing user name really required?
Username is part of MySQL client-server protocol. When somebody connects
he does it under a specific user name, that is, one claims to be a user
XXX. And a password was used to verify this claim. This is called
authentication. Now a plugin can verify this claim without a password too.
Simply replacing user name is not a good idea as it'll allow basically
anyone to connect without any user name verificaton.
I can do that in 5.5 - where a new user name is verified against the
proxy table. Or fix 5.2 to verify the new user name against the user
table. I'd rather wait for 5.5.
> I would understand providing extra name information if it would help
> to resolve some ambiguity. For example, it addition to user name it
> could be a group name. Given a token, checking that supplied string is
> either user name or one of the groups he belongs to, is simple.. From
> my point of view, allowing groups could make it more useful in
> practice ,allowing many different users/applications act as the single
> MySQL user, reducing the need of one-to-one mapping for every single
> OS user on MySQL level.
Yes, I thought of it, but slightly differently:
* I don't quite like the idea of using user name or group name, whatever
works. I'd rather specify what to use - user or group name - in the
CREATE USER xxx IDENTIFIED VIA windows USING 'GROUP';
where GROUP is not a group name, but literally a string "GROUP",
meaning that the plugin should look at the group name instead of the
* I'd like to do this at the same time for all plugin where it make
sense - for socket_peercred, for pam, and for windows auth plugins. So
I see it as a separate feature, common for many plugins, not specific
to windows plugin. Which means - done in a separate changeset.
> I'm afraid .Net connector does not work without mapping, or are
> things have changed in the last months? That would be pity, and
> greatly reduce the utility . Does any connector apart from .NET
> support authentication yet?
I didn't try any.
What do you mean ".Net connector does not work without mapping" ?
> Ok, to the itself. I do not think comparing usernames as strings is the
> correct way to go
> + if (!client_sid.is_valid() ||
> + !client_sid.make_username(buf, sizeof(buf)) ||
> + stricmp(info->user_name, buf))
Yes, you said that already.
Sorry for this.
I didn't do any comparison originally, and just returned 'buf' as the
user name. Then I added the comparison, almost right before pushing.
I'll fix it.
> The problem with it is that usernames can be really specified in multitude
> of different ways (name, .\name, machine\name are different names for the
> same local user for example). A more robust comparison would be retrieving
> SID for info->user_name, and comparing it with client_sid using e.g
For comparison - yes. But if I simply want to return a user name?
> Could you understand a strange dance around 254 bytes in Rafals code
> (Handshake_client::write_packet)? I do not get it. Did he fix a real
> problem, or problem that would not exist, or did he redefine protocol in
> his own way ?
There is a real problem - the length of the plugin data in the first
client response packet is sent in one byte. So it's limited to 255.
Rafal fixed this in a plugin, by sending second packet with the rest of
Which is a bad solution, this should've been fixed in a protocol by
storing plugin data length in more bytes.
I didn't do that for compatibility reasons (with .Net, for example).
On the other hand... I'd better fix the protocol and the plugin. But in
the server part of the plugin I keep the support for Rafal's protocol
workaround. I all this is possiblle, that is. If not - I'll keep
everything as is.