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 in charge for migrating old Access 2007 project to MS SQL server 2008 Express. The first stage is to move all the data from MS Access database to SQL server while keeping the Access forms and reports at the client.
So, the data are now moved, an SQL server user (for accessing only that particular database) created, and the tables are linked the Access database via ODBC connection. However, there's one nuisance that should be somehow solved: the Access regularly asks for the user password, when opening the Access database.
The users on server PC and client PC both log onto their local machines, ie their users are not verified on independent domain server.
I see there are several ways how to solve this:
1) Configure the integrated security model so that the user can log on, being automatically authorized by his Windows login (ie, use "trusted connection"). I am not sure how this could be done, given that the server PC does not recognize the user from client PC. If I try to do this now, I get error that the user is connecting from untrusted domain.
2) Store the SQL server user password at client side. I am not sure this is possible, though. I am aware keeping password in some config file, or stored obfuscated in application configuration should be considered lowering security, but this is acceptable for the given setup.
3) Perhaps some other way how to link the SQL server tables into Access?
The best solution is obviously to use Windows security.
If that is not suitable, here is a possible alternative trick, exploiting the fact that Access remembers all opened connections until the program is closed:
copy the connect string of one of your tables
create a passthru queries "ptqConnect" and enter any fast SQL statement in it, like SELECT 1
paste the connect string of into the PTQ Connect property, and make sure you add the PWD=something; in it.
in the startup procedure of your app make sure you call that PTQ. Something like DCount("*", "ptqConnect") will do.
That's it. Since Access remembers opened connections until you close it, even if you close the db, your other tables will now open without any fuss, even if no password is stored in the linked tables Connect string.
If you don't want to expose the connection string that includes the PWD, you could as well initiate a connection from VBA and hide the code by delivering a MDE or just password protecting the code.
You can find an explanation of this behaviour here.
Inform the users your organization's security policy prohibits storing passwords. Therefore they must provide their password each time they open the database. Explain that this policy will deny an unauthorized user the ability to open the database from an authorized user's machine. If the password were stored in any fashion, a miscreant could simply sit down at an unattended machine and open the database.
Since you can't use a trusted connection, this is the safest way to do it. Yes, the users will have to supply their password each time they open the database, but that's what it takes to keep the data safe.
Edit: Since your option #2 is acceptable, you can just store the uid and pwd in the connection strings for the ODBC-linked tables.
Here is an example copied from connectionstrings.com
Driver={SQL Server Native Client 10.0};
Server=myServerAddress;
Database=myDataBase;
Uid=myUsername;Pwd=myPassword;
I split the single line string for browser display. You'll need to also identify which table each of the links points to; examine your current link connection strings to see how that is done.
The uid and pwd will be plain text, and visible to anyone who can view the connection properties. But I didn't see any indication those are concerns for you.
I have had this issue, with Access 2010, linking to SQL Azure, but it was very simple. When linking the tables, there is an tick box option with each table to save the password.
Relinking your tables and checking this option would sort the issue. It does give you warnings that this may not be secure, but not all databases contain confidential data.
Just ran into this problem connecting remotely to my workplace sql server using Access. I have Access 2013, but I don't think it has made any changes to something so basic as as ODBC connection from 2010. Since it is not a trusted connection, yes, you will have to log into the server each time you connect to the database. This is just basic security; can't think why you would ever want an app to just connect from an untrusted network unchallenged. So, I expect to have to log in when opening the database.
What was driving me crazy, however, was that each and every time I tried to open a table, I was asked for the password, and not just once, but twice, and I have to use a 13 character password that was randomly generated at creation! So, needless to say, that was completely unacceptable.
Access keeps the connection information in the sys table MSysOBjects, but I doesn't store the password, at least not there. I use an access DB stored on a cloud server synced with my desktops so I can open a local copy rather than having to remote in to my work desktop. It's much faster this way.
But, using the db in Access as a local file means that I have keep a close eye on the DSN connection names. As long as they are absolutely identical on all computers, it works great. So, if named my DSN "ProductsDBIII" when I created it at work in the ODBC32 Windows tool, then I need to use that same name when creating it at home. The actual connection string will be different, but Access doesn't care about that. However, here's the trick: when I first the DB from home, for instance, after a day at work, then I have to refresh the connections in Access's Linked Table Manager. Just check the tables/views you need, or "Check All", and go. Access will make the connection--probably prompting you for the log in--and then quickly refresh the "connect" string field in the MSysObjects table because they will be different, at least if switching from trusted access.
Voila, no more single or double challenges every frickin' time I open a table. I will get asked once when I first make a connection the first time I open a table from the remote DB, but that's it.
Hope this helps someone.
Jim
Re the use of Passthrough QAuery to set ODBC connection.
The form quoted as the startup form in the Database options will fire BEFORE autoexec.
So that form cannot/should not quote linked tables,
or
Leave that none; and set the form in autoexec.
Otherwise you will still be prompted for pwd for the ODBC connection
A typical problem scenario is using a Switchboard form with the table in the linked database
I am just a beginner, as such, humbly request you to be as basic as possible.
below are the steps that I had taken while creating a split access database:
Originally created an access database in access 2013, which had a login form as default form on load, and it was mandatory to log in.
Split the database into back-end and front-end.
stored the back end database over the network in one of the computers (all systems are linked via LAN/wi-fi) and distributed the front end to different users.
This setup had worked fine so far. Users were able to operate the database perfectly fine. However, it was required that the database be imported back again (merge front-end and back-end). Below are the steps that I took.
Logged in as a superuser (there is a feature where I can bypass the login form by using shift+enter key, which then asks for superuser credentials. Once logged in, simply close the database and again open using shift+enter) and gained access to database design.
deleted the linked table, and imported the back-end database.
Now, when I connect my system to the network, and try opening the database, everything works fine. But if I disconnect from the network and try to open the database, IT JUST WON'T OPEN. Only the access software gets opened, and not the database.
What I fail to understand is why is my database still dependent on network when there clearly is no need for that?
Please help me understand where I am wrong, and also, how can I open the database without being connected to the said network.
(As per this meta post, I should repost my comment as an answer).
There were still linked hidden tables present. See here how to unhide them.
I've spent all day trying to figure out how to properly set up MongooseIM to use ODBC with MySQL.
Here's my ejabberd.conf: http://pastebin.com/Lyptf4Jm
I can register a user with the command mongooseimctl register user domain.example.com password
And I can see that the password is indeed correct in the users table (though stored in plaintext, which I want to change if possible) but I can't connect from Pidgin. I get "Not Authorized".
This is only one in a list of issues I'm having with MongooseIM at the moment, but it's the most important one right now. Can anyone help or at least point me in the direction of a document detailing what needs to be done to set up MongooseIM to properly work with MySQL?
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?