maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxxx>]

Hi, Vladislav!

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:

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

* 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
> EqualSid().

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

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.

Regards,
Sergei