I'm currently in the process of implementing a monitoring system, part of which includes monitoring certain aspects of a MySQL database, such as:
The replication state of the given MySQL instance (sys table)
The number of records in database 1's table x (db1.tableX)
The sum total of a given attribute in another db's table (db2.tableY.column3)
These 3 things can be found using very simple queries:
SELECT viable_candidate FROM sys.gr_member_routing_candidate_status
SELECT COUNT(1) FROM db1.tableX
SELECT SUM(column3) FROM db2.tableY
However, this then requires a user account to be made with at least read access to 3 entire databases / tables.
Is there instead a way to limit access to the results of given queries only? I wondered about making an additional database which is somehow linked to the output of the above 3 queries, and then creating a new user with access only to this database, but I'm not sure what this technology is, or how it would work?
Thanks in advance!
Create a view based on each query and then grant only a select permission to such view.
Example:
CREATE VIEW dbo.view_name AS
SELECT viable_candidate
FROM sys.gr_member_routing_candidate_status
And then
GRANT SELECT ON dbo.view_name TO 'user1'#'localhost'
Related
We've recently added a few restrictions as to what data an analyst can retrieve - specifically the password column in a users table.
The problem is she has thousands of queries which feature SELECT * from users, or joins, etc etc, in his scripts.
Now, when she attempts to run these, MySQL returns:
SQL Error (1142): SELECT command denied to user 'foo'#'bar' for table 'users'
The RDBMS is actually AWS Aurora MySQL 5.6.10a, if this helps. The analyst is reading from a read-replica, so has no write access, but can use and create temporary tables.
Is there a MySQL setting or something we can do, rather than getting the analyst to specify every single column?
I've found that it's possible to grant user access to only specific tables in a DB. The next part of the puzzle is restricting the scope of select queries.
Should my frontend server ever be compromised by someone able to script, they may attempt to use mysql credentials from the server to dump the database.
If everything is limited to only select, update, and insert queries via mysql privileges, the supposed malicious user could still select * on the tables the mysql user has access to. Perhaps I'm overly paranoid, but I'm wondering if anything can be done to restrict that too.
The assumption here is that if the server is compromised, the mysql user can be used via a script on the server to get a copy of everything in the DB. I'm trying to find the options to protect my (and my users' data).
By design, the frontend application that will use this mysql user will never need to return more than 20 rows (mostly due to hardcoded . I'm therefore happy to restrict the mysql user from ever getting more than 20 rows from a select query.
Can this be done using mysql privileges for that mysql user?
You could create view as select ... limit 20, remove select privilege from the table and grant it only for the view instead.
I would like to understand how hard this is to implement.
In unix, there are unix groups where certain people with a group can access certain folders and files.
I would like to apply the same concept into MYSQL where people could only access, view certain tables or even same tables but different rows ...
How can I achieve this? Would I have to use a different database system?
Gordon
This is a very common and simple approach. You can create users and specify which databases/tables they can access and what type of operations they can execute. See the mysql documentation on this
For instance:
--create the user
CREATE USER 'gordon'#'localhost' IDENTIFIED BY 'yourpassword';
--specify table and specific operations for that user
GRANT SELECT,UPDATE,DELETE,INSERT ON database.table TO 'gordon'#'localhost';
I'm looking for a flexible MySQL database schema to save logs.
Currently I'm using this one (simplified for the example).
Bigger version: http://i.stack.imgur.com/b6NC9.png
I can do a select * from log, get the log_type and read the specific table.
If log_type:tag is user, the specific table will be called log_user.
To add logs for an application I will add a tag application into log_type and
create a new table log_application.
To read all logs for a user, I do a select SELECT * FROM log_user INNER JOIN log ON log_user.logid=log.id WHERE userid=123.
This is actually working very well and flexible I would nevertheless be interested if somebody has a better idea for such a database schema.
you do not need 3 tables to store logs. Just use one flat table to achieve the same objective. This will save you from doing a lot of unnecessary coding.
I have a linked table set up in Access to an Oracle 10 enterprise server. It works great on my computer. But I'm trying to get a co-worker set up with the same functionality, and for some reason, she can't see all the columns in the table. It connects, refreshes, says it's linked, but not all the columns are there. Using a different client or sql on command line we can see the whole table. Just not in Access. The only difference is that I'm using Oracle 9g Client and she's using Oracle 10g Express. Any ideas?
Look into what HansUp stated about caching. There is one point I'd like to make. Ensure your co-worker is selecting from the same schema and same table. Multiple schemas (users) can have similar table names.
Example:
User a has table x with columns x,y,z
user b has table x with columns x,y
If you log in as user a and select * from x then the columns you will receive is x,y,z
if you log in as user b and select * from x then the columns you will receive is x,y
Either ensure you are logging in to the correct user or explicitdly state the schema you want in the select i.e. select * from a.x;
And the winner is... a table with more than 255 columns! For whatever reason, the columns that I needed for my query were available the first time I ran it, and were available to my machine in all subsequent runs. For my co-worker, for whatever reason, 2 of the columns we needed were considered in the 255+ category.
The work-around is to use a pass-through query on the linked table in Access. And yes, I agree - 255+ columns in a table/view is HORRID design. Not my fault, just need the data!!