From phpMyAdmin, I was exporting the functions/procedures used by the user assigned to a particular database and 3 functions didnt get exported because they were created by the 'superadmin'.
I was able to see these functions within
localhost > database_name -> Structure -> Routines
BUT, I was not able to modify their structure or export them.
The problem was happening because these 3 functions were created by the superuser. When exporting from the superuser account, everything got exported properly.
My question is: as a process, how can I ensure that this doesn't happen again in the future - that someone accidentally creates it as a superadmin (and the site would continue to work fine), but when we try exporting it, the function doesnt get exported (and the new site would stop working).
Restricting access to the superuser account would be the first step I would take. By restricting superuser access you guarantee that no one makes that mistake again. Is there a reason someone would need to be in the database working as a superuser?
Related
I sort of have a heart attack of a problem. I had a non-root utility user in mysql that used to be able to see all the databases, tables, etc. on the mysql instance. The user was also able to insert records, delete records, create tables, etc. too. This user is used by scripts to edit records, or view the data as someone who's not root via phpmyadmin.
I don't know how Django fits into this or if it was even the cause but a contractor needed access to the db to work on their project we asked them to work on. They said they were using Django and needed to create some auth tables in the database (auth_group, auth_user, auth_user_groups, etc.)
However, after they added their tables for Django, that utility user can't see anything except the "information_schema" database.
Luckily, I checked using the root user in mysql and can see the databases but somehow, I still cant see the databases with the non-root user. I don't see anything that jumps out at me permissions-wise in the "user" table in mysql so I'm not sure how to fix this problem. I want to see what commands the contractor ran to get us into this situation to tell them not to do this again.
I was going to check the .mysql_history file in the unix root user directory but the funny thing is the file is dated from 3 weeks ago so it doesn't look like this will yield any info on what was run.
So, back to my original question, where can I see a history of mysql commands that were run on mysql so I can figure out what happened or what was run to get us into this funny situation?
I am attempting to move all my vb scripts that refresh my Access Tables and Queries to our new server which I log into remotely. I have done without problem with most of my scripts however there are a few that will now work and the thing they all have in common is they have linked tables from other Access databases in them. I run a script to refresh the that table and it works fine so it shouldn't be an user access problem. I haven't been able to find anything online about it, it's very strange. The linked table is in a database that is on a shared drive but again I refresh database tables from that shared drive all of the time without issue unless there's linked table involved. Help!
So right after I posted this I figured it out, hours of my time spent and it ended up being the most irritating thing. I had mapped the drives under the mapped letters in the databases instead of the actual address on the server.
EDIT: Please ignore the Database Type "MySQL". I have it set to H2 currently, I was just playing around with settings at the time of the screengrabs in an attempt to see if I could pinpoint what was going wrong.
My friend came to me tonight with an "Opportunity". He had a college student code a front end application to insert, update, delete, and view data on a local drive for a small company that he runs. The application broke when he updated windows, and now he needs to retrieve the data. He sent me the .mv.db file, so I did some digging and found that DbVisualizer could allow me to atleast use a simple MySQL query to pull his data out into an excel spreadsheet. According to him, there are only about 300 records in the database.
When I connect to the embedded H2 database, it opens up two empty databases.
Let me know if anybody knows what to do here. Thanks.
I ran into the same problem. Luckily my database was small as well so I could use SQuirreL SQL Client to open the database. It is not easy to get used to the user interface but it does a really good job.
If you want to export your data you probably want to change the settings (File -> Global Preferences, Tab SQL Script). I unticked the box 'Qualify .. with schema' to get valid SQL.
Also the date format is not standard conform. I used a text editor to get executable SQL.
Environment: Ubuntu 11.10, MySQL 5.1.58
I have a small database with views. When I try to dump and restore, I get
ERROR 1356 (HY000) at line 1693: View 'curation2.condition_reference_qrm_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
However, I can connect to the partially-restored database and create the view myself. Therefore, I suspect that the error message results from an issue unrelated to the view itself (but rather how it's restored, perhaps).
Here's the simple approach I use to demonstrate the problem:
MYSQL_PWD='xxx' mysqldump -u root --routines -B curation \
| perl -pe 's/`curation`/`curation2`/' \
| MYSQL_PWD='xxx' mysql -u root
There are many other reports online of similar problems. The mysqldump man page has a cryptic note about bugs with backing up views, but it's written as a historical problem rather than a current one.
So, the question is: Can MySQL reliably restore backups that contain views or not? If it can, how? If not, what do people do as a workaround?
Thanks,
Reece
This question is a bit old, but I've just wasted a couple of hours trying to solve the exactly same issue, so I guess a clear explanation could come in handy to someone in the future...
To cut to the chase: The problem is in the DEFINER field in your mysql dump. It looks something like:
/*!50013 DEFINER=`some_user`#`localhost` SQL SECURITY DEFINER */
The problem is that this *some_user#localhost* will always be hardcoded to the user account that was used to create the view in the original DB and NOT the user that you've used to export or import the database as one would expect (or at least I did). And later, during the import, this user will be used to re-create the view.
So you can export/import as root, but if the original DB is running under another user and it has no CREATE VIEW rights in the new database, the import will fail.
You have two simple solutions:
Search and replace all references to some_user#localhost in your dump file with your new user (the one you use to import the dump, e.g. root#localhost)
Or you can grant *some_user* appropriate rights on the new database so that views can be created under his account
Either way will fix the problem, but I think the first approach is way better and cleaner, as you don't have to worry about multiple users in the future.
What I found to solve the problem is to use the 'sql security invoker' when creating the view initially.
create or replace sql security invoker view <VIEW_NAME> as select ...
It defines access to the view by the invoker, and not the definer.
Then when the dump file is loaded, the view is create correctly.
With Amazon RDS:
To make this work with Amazon RDS, which does not allow super priv (which is needed to do the above) one can run this command to on the dump file:
# Remove DEFINER statement from VIEWS in Dump file
sed -i 's/\sDEFINER=`[^`]*`#`[^`]*`//' $DUMPFILE_NAME
Then when the dump file is loaded into an RDS, the view is create correctly.
I found the problem in my case. I'm unsure that it solves similar reports on the web.
This was fundamentally a permission problem that resulted from trying to copy this database to a new name. Permissions didn't exist for this user and schema (locus on curation2). I manually added 'GRANT ALL ON curation2.* TO locus' (locus is the user reported in the error). After doing this, the above command line worked fine.
The lesson is that one must manually grant necessary permissions to the destination database and tables when creating a new database.
Couple of things:
1.) Yes, you can create the views using some client BUT perhaps the owner of the tables is not the owner of the view, which leads to
2.) Usually, doing backups of views in mysql includes some "useless garbage" like
create algorithm xxx definer=<USER> sql security view <view_name> as ....
and that user often includes the IP or machine name the user logged on when creating the view... SO, the view won't create properly. Check that out, might help you.
We have an access database on a file share that has permissions for everyone in the department to access. The problem i am having is that when multiple users try accessing the database at the same time they are unable to do this. One user can open the database fine but when another user tries to simultaneously, they double click the file icon, get an hour glass for a split second and nothing happens after. We are using Server 2003 as our domain controller. All permissions have been verified on both a domain level and in the access database under tools-options-advanced and setting relevent permissions to shared and no locks. Do you know what could be causing this issue with a "dead link" when user try to open the file simulateneously?
Any help is greatly appreciated.
Thanks.
Ignore the naysayers - Access is perfectly fine for a small number of users. Either you have the default Access settings to open dbs exclusive which will lock out other users or there is some weird network problem.
EDIT
- noticed you already have default shared access
- is record-level locking on?
- also try giving user full control of the shared network folder (Access needs read/write/create/delete to be able to create and delete the ldb file)
This issue occasionally happens to Access databases for almost no apparent reason. Of the suggested responses by Microsoft, you are already doing the second (opening from within Access) but I believe the first provides somewhat of the answer you are looking for.
In the target of the shortcut, include
the path of MSAccess.exe
According to Microsoft Help and Support
When you say share permissions, do the users have full permissions? Full permissions are needed because the share file (.ldb) must be created and deleted.
I am just recently experiencing the same issues, only one person can open the database. We only have 3 people accessing the same database through shorcuts on our desktop.
Now according to Microsoft we need to include the database path in our shortcut, I will tried that. They acknowledge this problem.
MS Access is not worth the trouble in a multi-user setup.
Your time is better spent converting the database over to a server-based RDBMS such as SQL server while you still have hair.
Believe me, you will have to do it sooner or later anyway! Sorry for the bad news.