There's a user who wants to view events, but what I know is that grant event will allow him to alter, drop, or create events and I don't want this to happen.
Is there any way to grant a user only allowing them to view events?
Btw, sorry with my bad English.
Thank you.
Related
So, having the database tables been managed by SQLAlchemy, I wonder if is possible to use it to, also, to administrate roles privileges, like, for example, create user read_user_a and give it read permission to a table, or revoking permissions.
When I log into phpmyadmin as the root DB user, I get a long control panel at the top of the page:
I am particularly interested in the designer feature. If I log on as another user, even one that has the same privileges as root, I see this in the same location:
How do I allow users other than root to have access to these extra features, particularly the designer feature?
A user belonging to a user group where some menus have been disabled can produce this effect.
I want to create a user that will have only read permissions
That it will be able to run SELECT queries but will not be able to run UPDATE,INSERT... or modify the DB.
I read that USAGE means - no permissions, what can it do?
Will a user with USAGE permissions be able to modify the DB?
In phpMyadmin you set priviliges according to your wishes. This meaning:
If you only wan't the user to be able to run SELECT queries, Thats what you select. The user will then not beable to edit your data in any way.
Hope this helps.
The best way to learn the capabilities of an account is to test it, try to create a test table and log in with that user, try also to execute the writing commands on it and you'll see by yourself if he can write or not.
https://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_usage
The USAGE privilege specifier stands for “no privileges.” It is used at the global level with GRANT to modify account attributes such as resource limits or SSL characteristics without affecting existing account privileges.
So no, a user with only USAGE will not be able to see or create other databases. They can connect, see information_schema, get STATUS, and very little else.
Anyway, you've mentioned phpMyAdmin which doesn't provide USAGE as a checkbox in the permissions area; creating a user with no other options selected gives USAGE privileges here. Select anything further you wish to allow from the checkboxes provided.
I am looking for an example or information on row level security for PHP and MySQL. I have done the basic google reasearch, I have read all the posts / articles about using views and adding fields to table to specify what user has the right to view the object. Those example are fairly simple and would require lots of configuration / maintenance.
Here are a few real life examples of what i am looking for:
Clients data, allow to configurer what user or user group can view all or parts of the client file. This must be persistent for all the application features including reports and dashboards.
Employee files, give access to immediate supervisor and HR to an employee file without having to reconfigurer the access rights when supervisors change.
I think this should be handled directly from the database layer, but could also be applied to other resources for examples, uploaded documents.
I'm hinting to some sort of "filter" that I could pass my data into so it could be filtered.
Any interesting links to articles or frameworks that have implemented this with success would be greatly appreciated.
Thanks.
You would need to use MariaDB to do this, as MySQL doesn't do ROLEs, though you might be able to use GRANT PROXY to accomplish what you want in MySQL.
I think that different "tenants", i.e. paying customers, should be in different databases to avoid leakage. You can use scripting to automate this.
But if you want intra-company row-level security, you can accomplish this with an extra column per table and some views and triggers.
create a table with an owner column. Use an insert trigger to set owner to the current user. REVOKE all privileges on the table.
create a view WITH CHECK OPTION on that table that checks that current user is in a role that matches the owner. GRANT all privileges on the view.
Example:
create user `pointyHead`;
create user `dilbert`;
create role `manager`;
create role `minion`;
grant manager to pointyHead;
grant minion to dilbert;
grant minion to manager;
Not sure if there is a function to check if user is in role, but you can always use information_schema.applicable_roles.
You can use column-level grants to give different column permissions to different users. http://dev.mysql.com/doc/refman/5.5/en/grant.html#grant-column-privileges .
The datasource used by my web application connects using the ROOT user. The ROOT user has all privileges assigned.
My concerns are:
1) Should I be using this user (and is it ok / secure) or should I create another user with a more restricted set of rights
2) If I do use another user, how do I cater for all my procs that begin with:
CREATE DEFINER=`root`#`%` PROCEDURE `Blah`()
3) Is it a bad idea removing privileges from the ROOT user. For example, if I remove the "DROP" privilege, will I still be able to DROP objects when logging in via the Admin or Query Browser. MY guess would be no and that I shouldn't mess with the privileges.
Any documentation / links / info regarding this would be appreciated. Thanks
You should absolutely use a restricted user to access the database as much as possible.
There are privileges that allow your users to access procedures. I'm not that familiar with it but here's the official documentation: http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html
Don't mess with root's privileges :)
No, your application should not connect using the root user. You should create and configure a user that has the permissions required by the application and no more.
I usually go with at least three users:
Root can do everything; changing root's permissions is a recipe for disaster (unless you know exactly what you are doing)
The application has its own user, and this user has very restrictive permissions - usually just SELECT, UPDATE, INSERT, DELETE on the tables it needs. In any case, no permissions that would allow schema modifications (CREATE / ALTER TABLE and such).
A special user which can access the application's database, but nothing else. This user is used for maintenance tasks such as schema upgrades, but not for the application itself.
It's a bad idea to use the root user for any task. You can see it like the system-user: only the system should use it, when it needs it, to do everything.
Create a new user and give it only access and priviledges to do what it should do. This is called the principle of least privilege.
In this case, procedures are part of what a certain user, module or part of a program should do in normal circumstances. Hence, the user you create owns (DEFINER) that procedure. You should remove the procedure from the root user and add it to your newly created user. If it's impossible to remove from the root user: then so be it! However:
If a user want to access the procedure, give (GRANT) them access to it. In the case the root user still owns the procedure, any other user still can be granted to use the procedure.
The root user is, as I already mentioned, the system user. If you drop priviledges then any program or user using the root can't do what is expected (being the system-user capable of doing everything), and this cripples your system.
Think about this: how would you add a new database, if you dropped the "ADD DATABASE" privilege from the root user?