I have created stored procedures in **MySQL database on my local machine and when i generate the script to run it on the host server i have this error**
#1227 - Access denied; you need the SUPER privilege for this operation
and this is the code
CREATE DEFINER = `User_name`#`host_name` PROCEDURE `InsertOrder`
and this user_name take all the privilege ,so any one can help please?
As the manual says:
If you do not have the SUPER privilege, the only permitted user value is your own account, either specified literally or by using CURRENT_USER. You cannot set the definer to some other account.
You must either issue the command using an account which has the SUPER privilege, or else change the DEFINER to your current user account (which is the default if it's omitted).
Related
I have one MySQL 5.6 running in production with a legacy root account that is used for years. As part of a hardening program, I wanted to remove this root account - make it available via another account not named root basically.
After creating another account named adminacc with full accesses on the DB, I deleted the account named root.
Right after this action, all (adminacc could still log in) my others accounts could not log in anymore receiving the below message
SQL State 28000 Error 1045: Access denied for user 'XXX'#'wathever' (using password: YES)
I granted the denied account full accesses on the DB - without success.
I finally recreated my root account (with the same previous password, not sure if relevant here) and my DB accounts went back.
How can it be there is a dependency between an account (would it be the initial root) and another in MySQL? Would it be because I created this other account while connected as root user? Or the other account is trying to query a view created by the root account? I believe not, just throwing thoughts trying to understand.
What I found the most weird in my senario is that the connection from the denied account was not completely denied. When testing the connection from a Windows odbcad32.exe utility, it succeedded! But whenever used in app context (running from the same windows host), it failed.
I did run a capture and here is the output (this is from the app context)
You can see the login actually happens well; few queries are executed properly (basically init statments at session opening like SET NAMES utf8 or SET SQL_AUTO_IS_NULL = 0).
Then the error is thrown when the user tries to execute a SELECT against one of the DB views.
Nota: I found no recommendation from MySQL docs to not delete the initial root account. Nothing describing such situation. Browsing a bit on the internet, I found this previous StackOverflow question but it remained unanswered.
As explained by Akina, this issue was tied to Stored Object Access Control in MySQL. Not only this applies to procedures, functions, triggers but views as well, read this
For stored routines (procedures and functions) and views, the object
definition can include an SQL SECURITY characteristic with a value of
DEFINER or INVOKER to specify whether the object executes in definer
or invoker context. If the definition omits the SQL SECURITY
characteristic, the default is definer context.
My errors actually appear whenever a view was called (and because all of the views were created via this root account and with the SQL SECURITY set to DEFINER - default behavior).
Making a lot of sense now. That being said, the MySQL error message could have been more descriptive on the actual issue!
Whilst a long time MS SQL Server user, MySQL is new to me. I've created an Internet site for a charity using PHP and MySQL. When I created the stored procedures in MySQL Workbench I didn't use the DEFINER parameter, so they are all set as the logged in account at the time, e.g. mysqluser#xx.xx.xx.xx The IP address was my home ip at the time, which has now changed. I now can't edit the stored procedures as I don't have the appropriate privileges apparently. Is this simply an issue with how Cpanel is used to create the MariaDb and the users, or can I alter how I write the stored procedures so that my IP is no longer important? I'm also worried that PHP login details might somehow stop working. Any help to relieve this confusion would be appreciated.
I'm not sure what solutions there are for your current circumstance, but to answer your question
You could use:
CREATE DEFINER = 'admin'#'localhost' PROCEDURE account_count()
or
CREATE DEFINER = 'remoteuser'#'%' PROCEDURE some_func()
As long as you have remote access to the host machine, you'd still be able to say for example ssh then login mysql as 'admin'#'localhost'.
Or login as 'remoteuser' regardless of your IP address, mind that wildcard host would not work if a user with the same name had a hostname that's more specific. Also privileges need to be granted to these users beforehand.
For DHCP, you can also do something with wildcard such as:
CREATE DEFINER = 'user'#'192.168.%' PROCEDURE do_sth()
Error in processing request: No routine with name 'daily_difference' found in database 'chamelis_wp'. You might be lacking the necessary privileges to edit this routine.
If you are using phpMyAdMin (pma) under cPanel, this error results from the fact that cPanel creates a temporary user for every session to log into pma, and therefore the database. If you are working in a hosted environment where you cannot be granted SUPER privileges, and you are creating routines, you are in trouble. Read on.
Stored routines (procedures and functions) in MySQL/Mariadb have a property called DEFINER. This stores the username of the the database user who "owns" that routine. If a db user opens phpMyAdmin (pma) and creates a new routine without explicitly declaring the DEFINER, DEFINER will be populated with the current username. Only a db user that has SUPER permissions can create a routine and declare another user as the DEFINER. Non-SUPER users can only declare themselves as the DEFINER, or leave it blank and the db does it for them. So the db user that you are logged in as gets to be the DEFINER for all routines you create during that session.
The problem you have encountered arises because
a. only the DEFINER of a routine, or a user with SUPER permissions, can edit or export a routine. If a (non-SUPER) user logs in to pma and tries to edit or export an existing routine, then unless they are the DEFINER of that routine they get the error you are seeing, and they cannot access the routine.
b. Even if you have created database user accounts in cPanel, cPanel will not use any of these to launch pma. Under cPanel you are automatically logged using a temp username that it generates. You do not get to see the pma login page - the login happens off-screen - and you are taken straight into the pma home page. You have no control over the username/password used.
d. When you start a new cPanel session (e.g. at the start of each day's work), cPanel changes the temp db user name that it uses to log you into pma. cPanel usernames all have this pattern: "cpses_db...#localhost", where the dots are filled alphanumerics like "hmxbj8s2". I have just logged in and the pma home page tells me that the current database user is "cpses_dbhmxbj8s2#localhost". If I close pma, log out of cPanel, log back into cPanel then reopen pma, the db user name will change. I just did that and the db user for this new session is "cpses_db0z35t107#localhost".
e. If I had created a new routine during my previous session, then the DEFINER for that routine would still be "cpses_dbhmxbj8s2#localhost". Now that I am logged in as "cpses_db0z35t107#localhost", I cannot edit or export that routine. Without a backup or copy of that routine, I have completely lost access to it (it is now, effectively, "orphaned"). The only way to get access is to recreate it using a script without a DEFINER statement in the current session so the the current db user becomes the DEFINER. That user can now edit the routine. This means that every day you would have to recreate all the procedures you want to work on. If you forget to export all the routines changed during the previous session, then you have LOST THOSE CHANGES.
f. Another problem is that if you are also connecting to the database externally using e.g. MySQL Workbench, logging in using a db user you have created, then you can do everything except edit any routines created under pma because these have "cpses_db..." user as the DEFINER.
THE SOLUTIONS:
Install your own copy of pma in your hosted enviroment if that option is available in cPanel. This will have to be installed in a folder in the public-html section of the site so you can access it directly from your browser e.g. https://example.com/pmamyadmin/index.php. Login using a user you have created for your database. This user becomes the DEFINER for all your routines and so long as you always use this username, you can always access your routines. (Never use cPanel's pma!)
Be aware that having a copy of pma in the public_html section of your site introduces security issues. Definitely require passwords in pma's config and if practical use .htaccess to limit access to just your IP, etc. But that's another topic.
Always access the database externally (assuming your host permits this) using a local copy of pma or another client like MySQL Workbench. Again, this allows you to control the username for every session.
FINALLY
If neither of these works for you and you must use cPanel's pma, then export all your routines at the end of every session and recreate them (with no DEFINER statement) at the start of the next session. Currently pma doesn't include the DROP in the routine export function (there a change request in for this) so you have to use a database export to get them included. Unless you want a full backup anyway, you just need to export the structure of one table to get this export to work. Make sure you click the "Include DROP..." and "Include Routines..." in the export definition. Edit the export to delete the table definition and globally replace the "DEFINER=cpses_db...#localhost" with "" before using it to recreate the routines next session.
Hope that helps.
I FIX THIS ISSUE IN CPANEL
This shows that there is lack of routines ( Function, Procedures ) privilege for the current user. This will cause even the edit button of routines to be disabled.
In CPanel there is default user that you can not manage their privileges, So, you can not add or remove their privileges.
<<<<< HOW I FIX IT >>>>>:
FIRST
Drop all routines(Function, Procedure) that you have no privilege from your database
SECOND ( import sql file again )
Find the sql file used to import database and remove DEFINER=root#localhost everywhere.
Then import Edited sql file after remove DEFINER=root#localhost .
I think this solution can help someone.
Thanks
It sounds like you don't have permission to edit it, or you're trying to edit it from the wrong DB (schema). Run the following to see which DB it is on:
show function status like '%daily%';
show procedure status like '%daily%';
Are you trying to edit it by executing a statement or by using the gui? If by executing a statement, can you provide your statement? If by statement, make sure you've run this first:
use db_name_here;
Then try to edit your routine again.
Did your user create the procedure, or another user created it? You may not have permission to modify an user's procedure. You can see who created it by running:
show create procedure daily_difference;
Then see if you have permission to edit procedures by running the below statement - you need "ALTER ROUTINE" privilege:
show grants for Your_username_here;
If a user with super privilege created it, you won't be able to edit it - you'll need them to, or you will need to get super privilege.
I'm replying partly as I have a work around and partly for the comedy, as GoDaddy sent me this page as a solution to this problem where, yes the problem is defined but no, there's no solution.
I had to rebuild my SPs in phpMyadmin but for the DEFINER where root#localhost was present, using an account I had created and could use - account#localhost. cPanel doesn't expose the root account AFAIK.
I didn't have all my SPs' definitions elsewhere. But I found that in cPanel \ files \ backup \ the files from there of the MySQL DBs had the SP definitions. That may not be in your hosting package. Backing up from phpMyAdmin didn't help as I still lacked the privileges to make the back up with the definitions.
I am logging in with my main DB user, into Phpmyadmin page/ workbench remote access application and I have permissions issues.
It all started when I tried to alter routines that I have stored in the DB. when trying to alter those routines from the workbench applications nothing just happens.
I can call these routines and execute them, but not alter or get to the scripts.
I searched for hours in distinct forums and get some answers regarding grant access commands
but then I got again permissions issues with error #1142 , command denied to user(main user).
I am really lost here, and already lost hours of work in order to get to the scripts of my routines.
one last note - I have created these routines while I was connected with the same user but from different remote connection (different IP address).
Would really appreciate the help.
here is a solution how I fixed this:
1) Add "mysql" database to the user, you are logged in with
Advice: now you can alter functions and procedures
2) Add the global privilege "SUPER" to your user
Advice: otherwise you will get the following error if you save the procedure/function: "ERROR 1227: Access denied; you need (at least one of) the SUPER privilege(s) for this operation"
CREATE DEFINER = 'admin'#'localhost' PROCEDURE account_count()
SQL SECURITY INVOKER
BEGIN
SELECT 'Number of accounts:', COUNT(*) FROM mysql.user;
END;
See the above example.
You need to login using super user and change the definer parameter in the procedure based on your new username and hostname. The same definer who created can edit the stored procedure.
I need to give an user TRIGGER permission for an whole schema in mysql to import mysql workbench backup.
I tried with:
grant trigger ON `schemaname`.* TO `user`#`localhost`
But while importing there comes the error that the user haven't the permissions.
ERROR 1142 (42000) at line 53: TRIGGER command denied to user 'user'#'localhost' for table 'table'
I tried to give the user TRIGGER permission to the table - that works, but of course only for that table, for the others still came the error.
Is there any way to give an user trigger permission to an schema without giving him the permission for every table separately?
From MySQL Docs
In MySQL 5.0 CREATE TRIGGER requires the SUPER privilege.
So you need to give SUPER privileges to the User. While importing, there will be command like "Create Trigger..." which is throwing an error.
Check your MySQL version and definer value as well for trigger in the importing file.
Edit:
For version 5.1, follow MySQL docs, that says:
CREATE TRIGGER requires the TRIGGER privilege for the table associated with the
trigger. The statement might also require the SUPER privilege, depending on
the DEFINER value, as described later in this section. If binary logging is
enabled, CREATE TRIGGER might require the SUPER privilege, as described in
Section 19.7, “Binary Logging of Stored Programs”. (Before MySQL 5.1.6, there is
no TRIGGER privilege and this statement requires the SUPER privilege in all cases)
The DEFINER clause determines the security context to be used when checking access
privileges at trigger activation time.
So, you need to check Definer value for importing trigger. It might have something like : DEFINER = root. Try removing the definer then try importing. Hope it works...
In MySQL docs:
To relax the preceding conditions on function creation (that you must have the
SUPER privilege and that a function must be declared deterministic or to not
modify data), set the global log_bin_trust_function_creators system variable
to 1. By default, this variable has a value of 0, but you can change it like
this:
mysql> SET GLOBAL log_bin_trust_function_creators = 1;
You can also set this variable by using the
--log-bin-trust-function-creators=1
option when starting the server.
Set the global variable and reopened the session I was able to insert the trigger