Hi,

I'm trying out MariaDB and I have a problem granting access to a user (that connects through JDBC).

Here is what I did (connected as root):

CREATE DATABASE hans;
CREATE USER hans identified by 'secretpassword';
GRANT ALL ON hans.* TO 'hans'@'localhost';

But when I connect as hans to the database hans I get the error message:
Access denied for user 'thomas'@'localhost' (using password: YES)

(I am using the correct password)

I also tried
GRANT ALL ON hans.* TO 'hans'@'%'
instead but that didn't change anything.

What am I missing? Is MariaDB different in this regard to MySQL?

Thanks for any input

You are apparently *NOT* connecting as 'hans@localhost', you are
connecting as 'thomas@localhost'. This might indicate some problems
with JDBC code where you establish the connection.


'hans' and 'thomas' are two different usernames.

> Thanks for any input

Hmm, my understanding was that this would be the same, but after changing it, it did work.
(I find this whole @localhost thing pretty confusing, but I'll get used to it I guess...)

Sorry, that was a copy & paste error in my post. I *am* using hans as the username

Thanks

On Mon, 13 Jun 2011 12:59:58 +0200, Hans Castorp wrote:

It gets worse. Wait until you find out that 'localhost' and '127.0.0.1'
aren't referring to the same thing. (;

--
I don't have a sense of humour, merely an over-exaggerated sense of
revenge.
-- Stephen Harris

It gets worse than that. Wait until you find out that "LocalHost",
"locaLhost", "LOCALHOST", "localhosT" and lOcalhOst" refer to the
same thing, but "localhost" is different.

In article <AMidnQOAqaLG62vQnZ2dnUVZ_qCdnZ2d (AT) posted (DOT) internetamerica>, gordonb.s4muw (AT) burditt (DOT) org (Gordon Burditt) wrote:

LOL. I din't know that but I am irritated by the fact that
I need to allow for:

"user"@"localhost"
"user"@"127.0.0.1"
"user"@"xxx.xxx.xxx.xxx" # My real IP
"user"@"myhost.mydomain.com"

Whether I'm seen as "localhost" or "myhost.mydomain.com"
depends on exactly how I make the connection. It's different
depending on whether I use MySQL Workshop or Perl:BI (both
via an SSH tunnel).

And I feel it's necessary to cover the IP's in case of any
lookup failures.

It sure would be nice if there was an easier way to
allow "local" users.


--

malch (AT) malch (DOT) com (Malcolm Hoar) wrote:
Is it really *that* hard to read the manual and to understand
that "localhost" (in exactly that spelling) is treated special
and means "connect through local transport" ?

because this is the special case

And those are /probably/ all different.
Depending on how the host name resolves.

It's the distinction between "uses local transport" and "uses
network transport". The question is rather: why do you use a
network transport (and the respective overhead) to connect to
MySQL from a locally running client?

For a tunneled connection it depends completely on how *you*
configure the tunnel. The client application does not matter
at all. If you use multiple tunnels with different configuration
then it's completely your fault.

In fact it's recommended to turn off DNS lookups in MySQL and
use IP addresses only (in production environments). Especially
on Windoze DNS is often broken and then causes strange delays.
But even on a UNIX box DNS can fail. You just don't want that
dependency if you can avoid it.


XL

In article <olejc8-7mn.ln1 (AT) xl (DOT) homelinux.org>, axel.schwenke (AT) gmx (DOT) de wrote:
I think not. In my case, I had only configured a single tunnel.
But to use Perl:BI and MySQL Workshop from the same client
with the same tunnel required me to allow for localhost as well
as the real hostname.

This was a major surprise to me because I *expected* it to
work in just the manner you describe.

Now, this makes sense and I contemplated doing just that. But
my Googling didn't suggest that this was a common practise
let alone a recommended one. A post in the MySQL forum went
unanswered.

In view of your comments, I'll make that change later today.

--

On Tue, 14 Jun 2011 09:19:52 +0200, Axel Schwenke wrote:
It's easy, if you're expecting it or even expecting "localhost" to mean
something other than the same thing it means in *every other context*.
If the local transport had been called "localtransport" or "local" or
nearly anything else, it would have been enough to cause people to think
"I better read up on this" instead of thinking that they already knew
what it was about. But that boat sailed long ago, and now it's easily
the cause of more than half of the newbie problems with authentication.

--
60. My five-year-old child advisor will also be asked to decipher any
code I am thinking of using. If he breaks the code in under 30
seconds, it will not be used. Note: this also applies to passwords.
--Peter Anspach's list of things to do as an Evil Overlord

malch (AT) malch (DOT) com (Malcolm Hoar) wrote:
Oh, now I guess I understand. Well, if you connect through the tunnel,
then from the MySQL servers point of view the connection will be
established by the sshd process (or ssh, depending which side opened
the tunnel). And this process is running on the same host than MySQL
itself and will thus connect from either 127.0.0.1 (preferred) or from
a public IP interface of your machine. Still you can configure how SSH
builds the tunnel.

If we assume that mysqld and ssh run on the remote machine and that
you establish the tunnel from the machine running the MySQL client,
then this would be like

ssh -L 6603:127.0.0.1:3306 ... $remote

to ask sshd on the remote machine to connect to MySQL at 127.0.0.1:3306
when your client connects to port 6603 locally. Of course you can use
a host name (will be resolved at $remote) or a public IP address
instead of 127.0.0.1. But MySQL will never be aware that the connection
uses a tunnel. It will asume the client to run where sshd runs.

There is http://dev.mysql.com/doc/refman/5.1/en/dns.html
it mentions a (small) performance penalty from having MySQL use DNS to
reverse-lookup incoming connections.


XL