GRANT SELECT ON source_starcraft.udb_ability TO `wade`#`localhost'
When I login with wade via PHPMyAdmin I can't see the database source_starcraft. I've only executed this query and created the user prior to this query.
Here something that helped me a lot. Actually I was working with MySQL Workbench.
http://bobfield.blogspot.it/2006/10/i-cant-see-my-databases.html
Briefly, it says that if MySQL has an <anonymous> account, and you fail logging in with your user, you end up logged in as the anonymous user, without notice. To find out this you can do:
SELECT user(), current_user();
Here's why:
One important thing to note is that SELECT USER(); shows you your
current username and host. Another command, SELECT CURRENT_USER();
shows what you're authenticated as.
Indeed, in my case, user() was mylogin#localhost, current_user() was #localhost (the anon user).
If the user you logged into phpMyAdmin with does have the correct permissions to view the database, but you still can't see it, it might mean phpMyAdmin itself has been configured to not show it. This is easiest to verify by issuing a show databases; SQL query from within phpMyAdmin. If the database you are looking for shows up, the user is permitted to view it, at the least.
There are several config directives which can controls which databases are visible in phpMyAdmin's lists. If you used an automated installer or script to add phpMyAdmin to a user account, it might also have set one of only_db or hide_db. These are also described in the official phpMyAdmin documentation, which should have been included with your installation, and on the wiki.
If your user has access to change the settings, you can do it for the current session from within phpMyAdmin under "Settings" and the "Features" tab. To permanently change these settings you will need to edit config.inc.php. Its location depends on where phpMyAdmin is installed on your system.
Seems like there might me some conflict/confusion with respect to which host the permission was granted to, and which one(s) are being used.
After FLUSH PRIVILEGES to remove that possibility, I'd see which user I was being identified as once I was logged in:
SELECT user();
Note that MySQL always associates a login with the most specific host. See doc. Then compare that to what's in the privileges database.
SELECT * FROM mysql.user WHERE user='wade';
SELECT * FROM mysql.db WHERE user='wade';
To resolve the situation, either REVOKE or DELETE+FLUSH PRIVILEGES the trouble-causing conflict (being careful not to paint yourself into a corner), or GRANT more privileges to the one your user is identified as.
I had the same issue yesterday. I swap my data files HD onto another MySQL server (Same version of everything, replica brand new install same passwords as preventive maintenance). Had both root access, but I guess they are different machines and hashs for the passwords created at MySQL startup. When I listed for files, all are intact in both servers, but phpmyadmin could't see databases (just information_schema), even not available using MySQL thru shell, but files are at the right location.
When check ownership of files they where not owned by root, the owner was 'nobody', so I proceded to take ownership of the databases files at MySQL default data location using chown root:root *
So if you think that just replacing the data by swapping HDs, and beeing root in both places, with root access on both you will be happy camper. But not so quickly, you may need to check persmission and ownership of those files still to be able to list them in PHPMYADMIN
After that procedure, everything worked OK after reboot.
Related
I was trying to access my root user remotely from any IP, so I found this snippet. Yes, I know it's a security issue but there's literally no sensitive information on the database.
Anyways, When I executed this statement it now says:
Connection for control user as defined in your configuration failed.
This is a very wide open ended issue that can have a lot of causes but it happened when I executed this query and now I can't login to root.
grant all privileges on *.* to 'root'#'%' identified by 'mypassword';
So I'm in a bit of a situation since I can no longer access my database.
Looks like you may need to get a bit clever.
If you can download a zip of the version of mysql you have installed and unzip it somewhere not in you actual installed mysql location. You can then rename the existing /data/mysql folder and copy the vanilla /data/mysql directory over your now messed up one. This should reset you to its initial state.
You will of course have to re-create all the other mysql accounts ( if you created any ).
And this time I would create a new account for your remote access, and if necessary give that all privilages.
I'm setting up a lamp server on my android phone, and i didn't managed to get mysql working with the default settings. i had to change the user to root in the my.cnf.
So i'm curious about the dangers of running mysql under the root user.
running MySQL as root, means everything the server does is also done as root (obvious). Especially if you happen to make a mistake, this can cause problems:
if you mis configure the mysql logfile to /etc/passwd, then that important file will probably be overwritten (a normal user cant do that).
root usually as some amount of disk system reserved (per filesystem), thus you can easier make the partition full as root.
code injection: if you have scripts running (for backup of the now root owned files) than you need higher privileges there, and again any mistake might have a bigger impact.
It is ok to login as a root user. However, use it to create new users with limited privileges on objects (tables, indexes, databases, etc) so that those users can't break anything other than what they're allowed to :)
Once the new users are created logout as root and login with those new users. I see you're using linux, so the idea of root user applies to MySQL in a similar way as in linux.
You can check the official documentation about this: Adding users and granting privileges
I was trying to create a very simple MySQL event and realized the action was not running. I then realized that the user I was using did not have super privileges (or any other event-related privileges). I tried granting all privileges to this user via phpMyAdmin but that wasn't working (makes since because I was logged in as that user and not the root user). In fact, I'm not sure if my account has a root user. How do I find out who the root user is (username and password)?
I'm using a hosting provider that has cpanel and when I look at a list of my mysql users I only see the ones I created. Is there a way I can find out via phpMyAdmin if I'm logged in as another user?
Also, whenever I create a user in cpanel, I always select the checkbox to grant "all privileges" but I found out just now that super priviledge and a few other privileges are not on the list. As far as I can tell, I won't be able to create any mysql events since I can't grant super privileges to any of my users.
Addition:
When assigning a user to a database, the only privileges I can select from are
ALTER
ALTER ROUTINE
CREATE
CREATE ROUTINE
CREATE TEMPORARY TABLES
CREATE VIEW
DELETE
DROP
EXECUTE
INDEX
INSERT
LOCK TABLES
REFERENCES
SELECT
SHOW VIEW
TRIGGER
UPDATE
From what everyone is saying in their answers it looks like I'm using a shared database, the event schedule is either turned off and/or I am not allowed to grant users privileges dealing with events. Kind of sucks..
But for now I will use cron jobs.
Rule of thumb: Your application never, ever needs superuser privileges.
Not even to use the event system.
The only thing you need SUPER for in this instance is to enable or disable the scheduler (which is a server-wide setting). If you're on a shared database host, it will be up to the provider whether or not the scheduler is enabled, and whether you've been granted the EVENT privilege on your database(s).
If you're not on a shared host, check your my.ini for the event-scheduler line and make sure it's enabled. Then, make sure you've granted EVENT to your application userid. The EVENT privilege should be granted if you've used GRANT ALL PRIVILEGES on the database (as opposed to on individual tables).
You'll need to contact your hosting provider and ask for event-related privileges for your account. They most likely store all their user databases under the same MySQL server, so for obvious security reasons root access can't be granted.
select user() would tell you the login that the query's executing under.
However, you should NOT grant 'super user' privileges to any code that handles DB operations for public-facing code. For proper security, public-facing DB code SHOULD have the minimum privileges required to get the job done. Usually that would update/insert/delete/select only.
Granting things like drop/alter/create/grant/etc... is just asking for trouble.
I was trying to create a very simple MySQL event and realized the action was not running. I then realized that the user I was using did not have super privileges
While reading this you might first implement better checking and handling for exceptions since this should release some error in your system for sure. This is a complex task requiring extensive handling of errors to see whether this goes right otherwise you will likely find yourself searching for a bug in this part for hours.
0.82sp1 running and i've noticed that every user can see all databases by invoking show databases; command. Even if i revoke all privileges for given user. Is there some setting that allows showing databases by default? How can i stop this.
DISCLAIMER: Stolen from ajreal comment
From dev.mysql:
If the server was started with the --skip-show-database option, you
cannot use this statement (SHOW DATABASES) at all unless you have the SHOW DATABASES
privilege.
I created a MySQL server. Now the user login has access to all databases. I want this user not to have access (so can't do anything) to 3 databases:
information_schema
mysql
phpmyadmin
So the user can use all databases except these 3. How can I get this done?
A brief version of how to do this (which is mostly explained in the link I posted above):
You need to REVOKE that user's GLOBAL privileges - this is because MySQL's privilege system is top-down. If they have a GLOBAL privilege to SELECT then that applies to all of your databases
You then need to GRANT the correct privileges on the ones it does need access to (you can use wildcards for this)
It's important to note that MySQL does not have any concept of a "DENY" privilege.