MySQL Grant All Commands? - mysql

I am trying to install daisy and I am following their install guide and running these commands as localhost root:
CREATE DATABASE daisyrepository CHARACTER SET 'utf8';
GRANT ALL ON daisyrepository.* TO daisy#'%' IDENTIFIED BY 'daisy';
GRANT ALL ON daisyrepository.* TO daisy#localhost IDENTIFIED BY 'daisy';
CREATE DATABASE activemq CHARACTER SET 'utf8';
GRANT ALL ON activemq.* TO activemq#'%' IDENTIFIED BY 'activemq';
GRANT ALL ON activemq.* TO activemq#localhost IDENTIFIED BY 'activemq';
The databases are created successfully but each of my GRANT ALL commands completes but it shows 0 records updated:
mysql> GRANT ALL ON *.* TO daisy#localhost IDENTIFIED BY 'daisy';
Query OK, 0 rows affected (0.00 sec)
I am running into a problem in the future of the install guide that seems to be related to this section. What am I doing wrong?
Additional info in the install guide about this section if it helps:
Now create the necessary databases, users and access rights by entering (or copy-paste) the commands below in the mysql client. What follows behind the IDENTIFIED BY is the password for the user, which you can change if you wish. The daisy#localhost entries are necessary because otherwise the default access rights for anonymous users #localhost will take precedence. If you'll run MySQL on the same machine as the Daisy Repository Server, you only need the #localhost entries.

What am I doing wrong?
Everything is fine. The query haven't returned any rows and didn't affect any rows (only explicit DML queries affect rows) - so you get 0

Related

Why use 'mysql_secure_installation' with MySQL5.7?

mysql_secure_installation is basically just a couple of SQL commands to make MySQL more secure.
I installed mysql-server 5.7 on Ubuntu 18.04 and ran the commands manually, as described here:
UPDATE mysql.user SET authentication_string='secretpassword' WHERE user='root';
DELETE FROM mysql.user WHERE user='';
DELETE FROM mysql.user WHERE user='root' AND Host NOT IN ('localhost',
'127.0.0.1', '::1');
DROP DATABASE IF EXISTS test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\\_%';
FLUSH PRIVILEGES;
Apart from changing the root password, each of the commands showed no effect at all:
Query OK, 0 rows affected (0.00 sec)
I have two questions:
Why would I want to use mysql_secure_installation if it does not
have any effect?
Why would I want to set a root password if I stick
with the default auth_socket authentification?
Note: As I am interested in the technical details, this is not a 'possible duplicate' of What is Purpose of using mysql_secure_installation? ;-).
Using mysql_secure_installation is not a must. No need to use it if you don't need it. As the document said in your link provided in your question, it is just for helping you implement security recommendation (ie, remote root access, etc) :
mysql_secure_installation helps you implement security recommendations
similar to those described at Section 2.10.4, “Securing the Initial
MySQL Accounts”.
https://dev.mysql.com/doc/refman/5.6/en/mysql-secure-installation.html
The default initiali here https://dev.mysql.com/doc/refman/5.6/en/default-privileges.html
If you are 100% sure will not get any remote attack or access from your local with default root access and any problem described there, actually you can ignore it.
Since this mysql is open source, actually you can know any technical details about any mysql problem with knowledge needed here https://github.com/mysql/mysql-server

UPDATE fails - SELECT denied

I have a mysql grants problem I can't work out.
mysql> UPDATE frontier_remote.trident_update SET completed=NOW() WHERE mac_address="00:1b:24:a0:da:e9" AND completed IS NULL;
ERROR 1143 (42000): SELECT command denied to user 'trident_client'#'host-78-147-8-82.as13285.net' for column 'mac_address' in table 'trident_update'
mysql> SELECT mac_address from trident_update WHERE mac_address="00:1b:24:a0:da:e9" and completed is NULL;
+-------------------+
| mac_address |
+-------------------+
| 00:0:de:ad:be:ef |
+-------------------+
1 row in set (0.04 sec)
So the update claims to fail in the select, but the select part of the command seems to work on its own.
The relevant entries in the grants table look like this:
GRANT USAGE ON *.* TO 'trident_client'#'%' IDENTIFIED BY PASSWORD 'shadow_password'
GRANT INSERT, UPDATE ON `frontier_remote`.* TO 'trident_client'#'%'
GRANT SELECT ON `frontier_test`.`trident_update` TO 'trident_client'#'%'
Any ideas what is going on?
Execute the following command:
FLUSH PRIVILEGES
Reloads the privileges from the grant tables in the mysql database. On
Unix, this also occurs if the server receives a SIGHUP signal.
The server caches information in memory as a result of GRANT, CREATE
USER, CREATE SERVER, and INSTALL PLUGIN statements. This memory is not
released by the corresponding REVOKE, DROP USER, DROP SERVER, and
UNINSTALL PLUGIN statements, so for a server that executes many
instances of the statements that cause caching, there will be an
increase in memory use. This cached memory can be freed with FLUSH
PRIVILEGES.
Documentation: FLUSH

MySQL error 1449: The user specified as a definer does not exist

When I run the following query I get an error:
SELECT
`a`.`sl_id` AS `sl_id`,
`a`.`quote_id` AS `quote_id`,
`a`.`sl_date` AS `sl_date`,
`a`.`sl_type` AS `sl_type`,
`a`.`sl_status` AS `sl_status`,
`b`.`client_id` AS `client_id`,
`b`.`business` AS `business`,
`b`.`affaire_type` AS `affaire_type`,
`b`.`quotation_date` AS `quotation_date`,
`b`.`total_sale_price_with_tax` AS `total_sale_price_with_tax`,
`b`.`STATUS` AS `status`,
`b`.`customer_name` AS `customer_name`
FROM `tbl_supplier_list` `a`
LEFT JOIN `view_quotes` `b`
ON (`b`.`quote_id` = `a`.`quote_id`)
LIMIT 0, 30
The error message is:
#1449 - The user specified as a definer ('web2vi'#'%') does not exist
Why am I getting that error? How do I fix it?
This commonly occurs when exporting views/triggers/procedures from one database or server to another as the user that created that object no longer exists.
You have two options:
1. Change the DEFINER
This is possibly easiest to do when initially importing your database objects, by removing any DEFINER statements from the dump.
Changing the definer later is a more little tricky:
How to change the definer for views
Run this SQL to generate the necessary ALTER statements
SELECT CONCAT("ALTER DEFINER=`youruser`#`host` VIEW ",
table_name, " AS ", view_definition, ";")
FROM information_schema.views
WHERE table_schema='your-database-name';
Copy and run the ALTER statements
How to change the definer for stored procedures
Example:
UPDATE `mysql`.`proc` p SET definer = 'user#%' WHERE definer='root#%'
Be careful, because this will change all the definers for all databases.
2. Create the missing user
If you've found following error while using MySQL database:
The user specified as a definer ('someuser'#'%') does not exist`
Then you can solve
it by using following :
GRANT ALL ON *.* TO 'someuser'#'%' IDENTIFIED BY 'complex-password';
FLUSH PRIVILEGES;
From http://www.lynnnayko.com/2010/07/mysql-user-specified-as-definer-root.html
This worked like a charm - you only have to change someuser to the name of the missing user. On a local dev server, you might typically just use root.
Also consider whether you actually need to grant the user ALL permissions or whether they could do with less.
The user who originally created the SQL view or procedure has been deleted. If you recreate that user, it should address your error.
Follow these steps:
Go to PHPMyAdmin
Select Your Database
Select your table
On the top menu Click on 'Triggers'
Click on 'Edit' to edit trigger
Change definer from [user#localhost] to root#localhost
Hope it helps
I got the same error after updating mysql.
The error has been fixed after this command:
mysql_upgrade -u root
mysql_upgrade should be executed each time you upgrade MySQL. It
checks all tables in all databases for incompatibilities with the
current version of MySQL Server. If a table is found to have a
possible incompatibility, it is checked. If any problems are found,
the table is repaired. mysql_upgrade also upgrades the system tables
so that you can take advantage of new privileges or capabilities that
might have been added.
Create the deleted user like this :
mysql> create user 'web2vi';
or
mysql> create user 'web2vi'#'%';
If the user exists, then:
mysql> flush privileges;
Solution is just a single line query as below :
grant all on *.* to 'ROOT'#'%' identified by 'PASSWORD' with grant option;
Replace ROOT with your mysql user name.
Replace PASSWORD with your mysql password.
Fixed by running this following comments.
grant all on *.* to 'web2vi'#'%' identified by 'root' with grant option;
FLUSH PRIVILEGES;
if you are getting some_other instead of web2vi then you have to change the name accordingly.
For future googlers: I got a similar message trying to update a table in a database that contained no views. After some digging, it turned out I had imported triggers on that table, and those were the things defined by the non-existant user. Dropping the triggers solved the problem.
quick fix to work around and dump the file:
mysqldump --single-transaction -u root -p xyz_live_db > xyz_live_db_bkup110116.sql
grant all on *.* to 'username'#'%' identified by 'password' with grant option;
example:
grant all on *.* to 'web2vi'#'%' identified by 'password' with grant option;
I had the same problem with root user ans it worked for me when I replaced
root#%
by
root#localhost
So, if the user 'web2vi' is allowed to connect from 'localhost', you can try:
web2vi#localhost
I'm connected remotely to the database.
The user 'web2vi' does not exist on your mysql server.
See http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html#error_er_no_such_user
If that user does exist, check what servers it can access from, although I would have thought that would be a different error (EG you might have web2vi#localhost, but you are accessing the db as web2vi#% (At anything)
This happened to me after moving the DB from one server to another server. Initially, the definer was using localhost and the user. On the new server we don't have that user, and host had also been changed. I took a back up of that particular table and removed all the triggers manually from phpmyadmin. After that it has been working fine for me.
Why am I getting that error? How do I fix it?
I spent a hour before found a decision for a problem like this. But, in my case, I ran this:
mysql> UPDATE `users` SET `somefield` = 1 WHERE `user_id` = 2;
ERROR 1449 (HY000): The user specified as a definer ('root'#'%') does not exist
If you really want to find the problem, just run this commands one by one:
SHOW PROCEDURE STATUS;
SHOW FUNCTION STATUS;
SHOW TRIGGERS;
SHOW FULL TABLES IN database_name WHERE TABLE_TYPE LIKE 'VIEW';
...and, after each of them, look for the field 'definer'.
In my case it was bearded old trigger, that somebody of developers forgot to delete.
My 5 cents.
I had same error while I tried to select from a view.
However problem appears to be that this view, selected from another view that was restored from backup from different server.
and in fact, YES, user was invalid, but was not obvious where to from the first look.
I had your very same problem minutes ago, I ran into this issue after deleting an unused user from mysql.user table, but doing an alter view fixed it, here is a handy command that makes it very simple:
SELECT CONCAT("ALTER DEFINER=`youruser`#`host` VIEW ",
table_name," AS ", view_definition,";") FROM
information_schema.views WHERE table_schema='databasename'
Mix this with the mysql command line (assuming *nix, not familiar with windows):
> echo above_query | mysql -uuser -p > alterView.sql
> mysql -uuser -ppass databasename < alterView.sql
Note: the command generates and extra SELECT CONCAT on the file, making mysql -uuser -ppass databasename < alterView.sql fail if you don't remove it.
Source: https://dba.stackexchange.com/questions/4129/modify-definer-on-many-views
Try to set your procedure as
SECURITY INVOKER
Mysql default sets procedures security as "DEFINER" (CREATOR OF).. you must set the security to the "invoker".
From MySQL reference of CREATE VIEW:
The DEFINER and SQL SECURITY clauses specify the security context to be used when checking access privileges at view invocation time.
This user must exist and is always better to use 'localhost' as hostname. So I think that if you check that the user exists and change it to 'localhost' on create view you won't have this error.
Your view, "view_quotes" may have been copied from a different database where "web2vi" is a valid user into a database where "web2vi" is not a valid user.
Either add the "web2vi" user to the database or alter the view (normally removing the DEFINER='web2vi'#'%' part and executing the script will do the trick)
In my case, the table had a trigger with a DEFINER user that didn't exist.
You can change the definer for a specific database to an existing user:
UPDATE mysql.proc SET definer = 'existing_user#localhost' WHERE db = 'database_name';
The problem is clear - MySQL cannot find user specified as the definer.
I encountered this problem after synchronizing database model from development server, applying it to localhost, making changes to the model and then reapplying it to localhost. Apparently there was a view (I modified) defined and so I couldn't update my local version.
How to fix (easily):
Note: it involves deleting so it works just fine for views but make sure you have data backed-up if you try this on tables.
Login to database as root (or whatever has enough power to make changes).
Delete view, table or whatever you are having trouble with.
Synchronize your new model - it will not complain about something that does not exist now. You may want to remove SQL SECURITY DEFINER part from the item definition you had problems with.
P.S. This is neither a proper nor best-all-around fix. I just posted it as a possible (and very simple) solution.
You can try this:
$ mysql -u root -p
> grant all privileges on *.* to `root`#`%` identified by 'password';
> flush privileges;
For me, removing the '' from the DEFINER did the trick.
DEFINER = user#localhost
Go into the edit routine section and and at the bottom, change Security Type from Definer to Invoker.
One or several of your views where created/registered by another user. You'll have to check the owner of the view and:
Recreate the user; as the other answers say.
or
Recreate the views that where created by the user 'web2vi' using ALTER VIEW
I had this problem once.
I was trying to migrate views, from BD1 to BD2, using SQLYog. SQLYog recreated the views in the other DataBase (DB2), but it kept the user of BD1 (they where different). Later I realized that the views I was using in my query were having the same error as you, even when I wasn't creating any view.
Hope this help.
If this is a stored procedure, you can do:
UPDATE `mysql`.`proc` SET definer = 'YournewDefiner' WHERE definer='OldDefinerShownBefore'
But this is not advised.
For me, better solution is to create the definer:
create user 'myuser' identified by 'mypass';
grant all on `mytable`.* to 'myuser' identified by 'mypass';
when mysql.proc is empty, but system always notice "user#192.168.%" for table_name no exist,you just root in mysql command line and type:
CHECK TABLE `database`.`table_name` QUICK FAST MEDIUM CHANGED;
flush privileges;
over!
in my case I had a trigger on that table that I could not update data getting the same error.
MySQL error 1449: The user specified as a definer does not exist
the solution was to delete the triggers on that table and recreate them again, this fixed the issue, since the the trigger was made with another user from another server, and the user name changed on the new server after changing hosting company . that's my 2 cents

NoAccessToProcedureBodies error when executing MySql procedure with CFStoredProc [duplicate]

I am connecting to a MySQL (5.08) database running on a linux machine from a web application running in tomcat.
I get the following exception when I try to execute a stored procedure:
com.hp.hpl.chaos.web.exception.DBException: getNextValue for operatorinstance[Additional Information from SQL Exception][SQLErrorCode: 0 SQLState: S1000
at com.hp.hpl.chaos.web.util.SQLUtil.getNextValue(SQLUtil.java:207)
..............
Caused by: java.sql.SQLException: User does not have access to metadata required to determine stored procedure parameter types. If rights can not be granted, configure connection with "noAccessToProcedureBodies=true" to have driver generate parameters that represent INOUT strings irregardless of actual parameter types.
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:910)
at com.mysql.jdbc.DatabaseMetaData.getCallStmtParameterTypes(DatabaseMetaData.java:1619)
at com.mysql.jdbc.DatabaseMetaData.getProcedureColumns(DatabaseMetaData.java:4034)
at com.mysql.jdbc.CallableStatement.determineParameterTypes(CallableStatement.java:709)
at com.mysql.jdbc.CallableStatement.<init>(CallableStatement.java:513)
at com.mysql.jdbc.Connection.parseCallableStatement(Connection.java:4583)
at com.mysql.jdbc.Connection.prepareCall(Connection.java:4657)
at com.mysql.jdbc.Connection.prepareCall(Connection.java:4631)
at com.hp.hpl.chaos.web.util.SQLUtil.getNextValue(SQLUtil.java:196)
... 17 more
After installing mysql on the machine. I have given the follwing grant options to root
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'#'%' IDENTIFIED BY 'pass';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
In the java class..
I am connecting to the db as follows:
String url = "jdbc:mysql://ipaddress:3306/test";
con = DriverManager.getConnection(url,"root", "pass");
I have also tried the url with the noAccessToProcedureBodies=true option included.
Can someone tell me what is wrong here? Is there anything I need to check?
There are two ways to solve this:
set the connection's noAccessToProcedureBodies=true property
For example as part of the connection string:
jdbc:mysql://ipaddress:3306/test?noAccessToProcedureBodies=true
The JDBC driver will then create "INOUT" strings for the arguments without requiring meta data like the exception says.
Grant SELECT privileges on mysql.proc to the database user
For example in the mysql prompt:
GRANT SELECT ON mysql.proc TO 'user'#'localhost';
Of course this would allow the application to read the entire mysql.proc table that contains information about all stored procedures in all databases (including source code).
Following steps worked for me in mysql
Step 1 : add follwong
Connection con = DriverManager.getConnection("jdbc:mysql://ipaddress:3306/logparser?noAccessToProcedureBodies = true ",
"root", "");
Step 2 :
GRANT ALL ON logparser.proc TO root#'%'; where logparser is DB name and proc is procedure name.
Running below queries should fix your issue.
GRANT <SELECT, CREATE, UPDATE, DELETE, ALL> PRIVILEGES ON mysql.proc TO '<user>'#'%';
FLUSH PRIVILEGES;
You can change the definer in the mysql.proc table to your database user.
select * from mysql.proc;
choose the stored proc that has problem and change the definer to 'yourdbuser'#'localhost'.

Setting mysql usernames and passwords

I have recently installed easyPHP at home to do some development work with my computer running as the server (Windows XP).
easyPHP sets up apache, php and mysql to work on your computer. I am having trouble setting the usernames and passwords for the mysql accounts (sadly, I've only ever done this through cPanel).
The easyPHP GUI lets you log into mySQL through what I assume is 'root' with no password but I'd like to change this ASAP.
Any advice? Thanks.
you can create a user by this command:
create user user#host;
example:
create user farzad#localhost;
and then you my set a password for the user. you can use this line to create a password for current user you are logged in:
set password = password('mynewpassword');
in the above command, the password() function converts the string parameter to a hashed password that will be used by mysql to authenticate users. if you use this line:
set password = 'mynewpassword';
then you have entered your string as your password and it is not a hashed value, so you will not be able to login again later. so do not forget to use the password() function.
to change password for another user, use this command:
set password for user#host = password('userpassword');
example:
set password for farzad#localhost = password('dalkXfda23423');
after creating a user and securing login with a password, you need to set permissions for the user. use the GRANT command to do this. general syntax is like this:
GRANT {PERMISSIONS} ON db.table TO user#host;
in this command, permissions are a comma separated list of permissions, like SELECT, INSERT, CREATE, DROP, DELETE. you can use ALL as a high level permission so the user can do most of the things.
db.table specifies the tables of a certain database where the user might do actions. so you can restrict a user to only a table of a database, or use the wildcard * to permit on all of tables or databases.
example:
GRANT ALL ON myDb.* to farzad#localhost;
if you have not created a user, or set a password, by using the grant command you can create the user, set the password for him, and grant permissions all at once. syntax is like this:
GRANT {PERMISSIONS} ON db.table to new_user#host IDENTIFIED BY 'userpassword';
example:
GRANT ALL ON myDb.* to farzad#10.0.0.1 IDENTIFIED BY 'dalkXfda23423';
Next piece of code (copied from http://www.debian-administration.org/articles/39) creates a user paul (#localhost) with a password, and gives it full rights to the pauldb database. All is done from within the MySQL prompt:
mysql> grant CREATE,INSERT,DELETE,UPDATE,SELECT on pauldb.* to paul#localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> set password for paul = password('mysecretpassword');
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
mysql> exit;
Well, if you're just looking for some way to change the root password, and you have a way to run SQL commands, you're looking for the "SET PASSWORD" command: http://dev.mysql.com/doc/refman/5.0/en/set-password.html
For creating other users and setting them up with access to particular databases, you're going to want to look through most of the parts of the Account Management chapter of the manual: http://dev.mysql.com/doc/refman/5.0/en/account-management-sql.html