I have MySQL Database and have several tables in it. One, of course, is the users table for storing the username and passwords (which also has the rest of their information). For all the tables in the schema, I want to be able to grant users (or groups) permission to individual fields. Maybe an example will help:
There;'s a table called ACCOUNTS. In this table, the user fills out (and keeps up to date) all the data about their company (name, address, POC, etc). But I also want to have fields attached to this table that are read only for those users, such as LastPaymentDate (can't have them changing that!). Further, among those users, permissions differ. For example, the admin/superuser can change the name and address of the company, but standard users should not.
I'm thinking this might need to be done by making several Views for the table, one for each level of permission (group). I'm relatively new to MySQL, so I don't know if this is the best way. I can also see a lookup table that says which fields is allowed to view/edit.
My initial thought was to include in the comments (or the name of the field) a value from 0-5, and then the user would have a permission level (0-can't see; 1-Read only; 2-Read-write; 3-(not used); 4-(not used); 5-Edit/Delete the field itself.
Any suggestions? Views? Lookup table to determine which fields to display? Again, it'd not for the whole table, for each column within a table.
You can GRANT the rights to individual columns to a user, using this code:
GRANT SELECT (col1), INSERT (col1,col2) ON mydb.mytbl TO 'someuser'#'somehost';
Example taken from here:
http://dev.mysql.com/doc/refman/5.1/en/grant.html
Also there is no support for groups of users or SQL ROLES (which are groups of privileges) in MySQL.
Related
We are new in relational database and we want to create program. In our database we have company table, project table, section table and user table. We want to give a permission which are read, write to a user.
But if that user belongs to project table then it has write and read permissions but if that user belongs to section table then it has only read permission. So, Our question is how can we decide user's permissions on mysql.
So far we did,
We have tried to use Grant but it cannot be using in table and it gives a permission only a spesific person. We want to give all the person which belogs to project (write and read). And all the person which belongs to section(only read).
This answer may be useful, something you did.
https://stackoverflow.com/a/12349845/12569575
Also at the same page, there is another solution made by trigger.
https://stackoverflow.com/a/37873439/12569575
I have read many posts and articles that state quite clearly that for the best in worst-case damage limitation, MySQL accounts should only be able to do what they're intended to do, and nothing else. This makes perfect sense and so there would be a connection account to my Database that does all the SELECTing of data, and another account that does UPDATE and INSERT activities, so that if someone does get the compromise by SELECTing data they shouldn't, then they can't quite as easily then UPDATE that data or INSERT etc.
You get the idea.
But, I have various Databases and use accounts to read/SELECT data and the this is output to the client page, but often these accounts will need to be updated, small things such as updating when a (website) user logs into their account, or updating some sort of hitcounter or other minor feature. Given the ringfencing of concerns outlined above, I feel it's a bit like using a flood to put out a campfire, to allow UPDATEing (etc.) to a privileged MySQL connection simply to say that user Bob logged in last at 4:10pm.
I have been digging on the web for suitable guides, blog posts and articles about how to best structure using multiple MySQL privileged accounts to complete the nessecary work with as minimum a risk of excess privilege as possible, but I have found nothing that has been much use, (mostly because of my wording seems to be attracting articles about setting up website users, or other topics associated with these keywords :-/ )
I have a few ideas on current approach and wanted a bit of feedback on the best method for doing activities as described in paragraph 2, typically 95% SELECTing, and a few specific instances of UPDATEing, or if any of the following are possible (or on flipside, are very bad ideas)? :
I currently have seperate PHP connection objects for each connection privilege user. Is this the best approach?
Could I somehow giving a privilege user access to only update a certain table (or even a certain table column?), as well as SELECT from any table? This would be perfect.
Are using TRIGGERs a common approach and would this have any down sides if I created a Trigger (with a privileged user) and then let a SELECT user account access triggers?
Could I set certain users can only use certain triggers?
Is there another way of doing this?
MySQL allows for users to have different privileges set both at database and individual table levels. The documentation on the GRANT (http://dev.mysql.com/doc/refman/5.7/en/grant.html) syntax gives an example of setting all privileges to a user on one database while only select access to a table in another database.
Privileges can even be set for specific columns (http://dev.mysql.com/doc/refman/5.7/en/grant.html#grant-column-privileges) in a table & also for stored procedures (http://dev.mysql.com/doc/refman/5.7/en/grant.html#grant-routine-privileges).
I have a database with two tables. The first one contains the user_name, user_password, user_email. The second one contains the user_name, user_age, user_description.
When a person finds the user he needs by the user_name, the script looks through the database using the user_name, to give out the information about certain user.
But if the person changes his user_name via preferences, the value changes only in the first table.
Question:
1) Is there a way to make the user_name in the second table change automatically? (To connect them some how)
I am using MySQL (phpMyAdmin).
This is just a simple example. In "real world" I am trying to manage more serious applications that have more tables. Is there an easier way than to create a separate php query for each table?
You could always create an AFTER UPDATE MySQL trigger targeting single rows for this. See the manual. It's probably not easier than using separate PHP queries for the tables, though. You don't need to spell them all out, just map up what needs to be synchronized when, and abstract your code.
However I'd recommend that you use a unique ID field for the user and only store the username in one of the tables -- and refer to the user with the ID under the hood of your code, and in both tables. Not a good idea to use something changeable as a unique identifier in your database design.
I'm currently creating a site with basic user signup and have all of the user data in one table called 'users'. Eleven of the fields such as username, role etc may be required by that user while they are logged in or by the script when displaying their details. While nine of the fields such as password, email, ip etc will only ever be accessed by the user when they login. If the database is expected to handle 100,000 to 1,000,000 users should I split the login related fields into a table called 'users_login' to reduce the size of the main 'users' table?
I know there are many variables involved and the best approach is to test both versions but before I did that I'm asking for advice on if I shouldn't attempt this for some reason. Thanks
Another approach, which does not require splitting the table, would be to create a covering index. A covering index for some query is one where the index entry itself contains all the columns needed to execute the query, meaning that execution does not need to read from the table itself. For example, for a query like select role from user where username = ?, then an index on (username, role) would be covering.
In your case, the covering index would on the eleven columns that may be "required by that user while they are logged in or by the script when displaying their details". You would need to put the column used as the key for the lookup (user ID or username or whatever) at the start, so the index would be on something like (username, role, and, nine, other, columns, used, frequently, while, logged, in).
Here's an example of the database team at Wikipedia using this technique to get a ~10x speedup in a very similar situation: Where covering indexes rock.
I have a table with a column that I want to prevent certain users from seeing. I understand that I should be able to do this using a view, i.e. have a view which excludes the particular column, and deny access to the table but allow access to the view (note, users do not need to be able to update the table/view).
I do however want to allow an equality query against the field. Such as:
SELECT * FROM some_table_or_view WHERE hidden_field = 'some_value';
To clarify:
it should not be possible to have the hidden_field values be returned in a general query
it should be possible to run a query with a constraint (preferably only an equality constraint) on the hidden_field value
Is this possible?
(EDIT: if there's a solution in a dbms other than Mysql, I'd be happy to hear about that, too).
You can create a stored procedure which would return all the fields you allowed it to return, and then you can pass the hidden_value (filtering criterion) as a parameter.
Forbid your database users accessing the table, but allow them to call stored procedures.
Then of course, you would have to create several stored procedures if you had several types of queries against the table. But at least it solves your problem with the rights.
No it is not. Giving a user a possibility to filter the results with the column hidden_value means that they have select rights, and that also means they can see the column, and therefore select it.
Here http://dev.mysql.com/doc/refman/5.1/en/grant.html
is a list of the rights you can grant or not grant to the users in mySQL.