Not quite. max_user_connections limit is enforced after successful authentication - that's when the server knows the user name.
max_connections is enforced as soon as the client connects.
So yes, even when usera has reached max_user_connections limit,
they
can keep trying to connect and exhaust max_connections too, especially if they'll delay sending authentication packets.
So what about waiting a bit with dropping the connection of max_connections, so you can do
- get the send user name - check if the username is in max_user_connections limit - if it is limited drop the connection, but don't add it to the max_connections counter. - if it is not limited add the connection, and add it to max_connections counter.
disadvantage - is when you drop the connection for max_connections. You have to maybe postpone this a bit. - could this postponing be abused in a dos attack?
Yes, it could. Currently when usera has reached max_user_connections limit, they can keep trying to connect and exhaust max_connections too, especially if they'll delay sending authentication packets.
But you already have timeouts for this not? I think that is a separate case.
If the server will delay enforcing of max_connections (that is, the server will not reject connections about max_connections at once), then this user in the above scenario will open all possible connections
Really? Mostly you need to delay until the n'th packet is received with the username. Besides you mostly are also processing requests from 'badly' operating clients. Who are not trying to dos the db server with some malformed tcp stream. These clients just send to many requests for whatever reason. So in ~90% of the cases you will just receive the username as with any 'normal' connection.
What delay are we then talking about? I assume the delay between initiating a connection and receiving the username is in the low ms?
your OS can handle and the computer will become completely inaccessible.
Besides is the limits.conf or so from your os not limiting the ports. I don't think it is currently that easy for a process to cause a dos on the os.
Currently only the MariaDB server will become inaccessible, but you can configure extra_port to always be able to access the server in such a case.
Yes, I am now restarting it even. The idea about this change is to have a more useful and expected implementation of max_user_connections and max_connections. Currently I am using max_connections not for what it is supposed to be used, just because the max_user_connections is not doing as much as it 'should'.
Hi Sergei, Is this something you are going to look in to? I am also curious about this delay between first package and package with the username. I can't imagine that being such a problem, to me this looks feasible currently.