I am building a database for students. I want the students to be able to perform any action on the database, create tables etc. I do not want them to delete the master table.
So far, I granted them almost all the permissions using this grant
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD,
PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES,
CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE,
REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW,
CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER
ON *.*
TO 'mta_student'#'%' WITH GRANT OPTION
However, how can I keep them from interfering with master_table I have?
a data table?
You can't revoke a specific privilege that hasn't been granted specifically. In this case, you haven't granted access per table, so you can't revoke access per table.
The only way to accomplish what you describe is to locate your master_table in a separate schema:
create schema main;
rename table master_table to main.master_table;
Then grant your students privileges on other schemas, but not the main schema.
grant ... on student_schema.* to 'mta_student'#'%';
Related
I am trying to grant a newly created user the ability to create tables.
I would have thought it would be
GRANT CREATE TABLE ON databaseName.* TO userName_3;
However, I receive a syntax error while trying to execute this SQL statement.
Would anyone be able to tell me why it is not working?
Thanks
Read this
SQL Server grand permission
GRANT CREATE ON SCHEMA :: databaseName TO userName_3;
For MySQL
GRANT CREATE ON databaseName.* TO userName_3;
You can't use the TABLE in the query
Table Privileges
Table privileges apply to all columns in a given table. To assign
table-level privileges, use ON db_name.tbl_name syntax:
GRANT ALL ON mydb.mytbl TO 'someuser'#'somehost'; GRANT SELECT, INSERT
ON mydb.mytbl TO 'someuser'#'somehost'; If you specify tbl_name rather
than db_name.tbl_name, the statement applies to tbl_name in the
default database. An error occurs if there is no default database.
The permissible priv_type values at the table level are ALTER, CREATE
VIEW, CREATE, DELETE, DROP, GRANT OPTION, INDEX, INSERT, REFERENCES,
SELECT, SHOW VIEW, TRIGGER, and UPDATE.
Table-level privileges apply to base tables and views. They do not
apply to tables created with CREATE TEMPORARY TABLE, even if the table
names match. For information about TEMPORARY table privileges, see
Section 13.1.18.3, “CREATE TEMPORARY TABLE Syntax”.
MySQL stores table privileges in the mysql.tables_priv table.
Grant INSERT without having it.
Suppose the following code snippet is executed every time a new manager is created (with different names for the database and user account each time, of course):
#Executed as root
CREATE DATABASE `Manager1Section`;
CREATE TABLE Manager1Data(`SomeData` INT);
CREATE USER 'Manager1'#'localhost' IDENTIFIED BY 'Something';
GRANT SELECT, INSERT, UPDATE, DELETE ON `Manager1Section`.`Manager1Data` TO 'Manager1'#'localhost';
GRANT CREATE, DROP ON `Manager1Section`.* TO 'Manager1'#'localhost';
GRANT CREATE USER ON *.* TO 'Manager1Section'#'localhost' WITH GRANT OPTION;
And the following code is executed every time a new intern is created (again, names substituted):
#Executed as manager
CREATE TABLE `Manager1Section`.`Intern1Data`(`Value` INT NOT NULL);
CREATE USER 'Intern1'#'localhost' IDENTIFIED BY 'Something';
GRANT SELECT, INSERT, UPDATE, DELETE ON `Manager1Section`.`Intern1Data` TO 'Intern1'#'localhost';
(Mind that this is just an example to show the hierarchical structure. I am not actually modeling a company's personnel structure.)
The manager manages a single database (Manager1Section in this example) and has a table to work with. The manager can only read and write to that table but not e.g. drop it. (Actually nevermind, I just realized that the manager can, in fact, drop the table. Not a big deal though.).
Each intern in this database also has a table to work with, and again, can only read and write to it but not drop it. Additionally, interns can only access their own tables, but not the manager's table and not other interns' tables.
And very importantly: The manager cannot read and write to interns' tables.
The above code would achieve this, but it is not valid. The last line in the second snippet fails. The manager does not have the SELECT, INSERT, UPDATE and DELETE privileges to interns' tables and therefore cannot grant those privileges to the interns. Changing the second-to-last line in the first snippet (GRANT CREATE, DROP ON `Manager1Section`.* TO 'Manager1'#'localhost';) to GRANT CREATE, DROP, SELECT, INSERT, UPDATE, DELETE ON `Manager1Section`.* TO 'Manager1'#'localhost'; makes that work but it also allows the manager to read and write to interns' tables, which I want to avoid.
How can I make the manager not able to read and write to interns' tables but still grant read and write privileges to interns?
Or alternatively: How can I avoid that problem altogether?
Only allowing users to grant privileges they already have is generally a good idea and my gut feeling tells me that my intended solution is not possible because the manager could circumvent the situation by creating a spoof intern account, executing GRANT SELECT, INSERT, UPDATE, DELETE ON `Manager1Section`.`Intern1Data` TO 'SpoofIntern'#'localhost'; (mind the mismatched user names) and then access the data through that account. But I could be missing something, so I am asking for ideas.
Before this post, I've got already posted, but i should delete that, because there was some misspelled column names, so that was my fault.
What i want to do is, to grant all privileges to a user to a database. These users will be our partners. My system designs require that, I need 1 table in every partners database, what I will use, and I want to prevent them from doing any operations, but SELECT on that table. (Please skip the WITH GRANT OPTION thing).
The name of the database and name of the user is the same, csp_ytic.
What i did:
CREATE USER 'csp_ytic'#'localhost' IDENTIFIED BY 'somepass';
FLUSH PRIVILEGES;
GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EVENT, EXECUTE, INDEX, INSERT, LOCK TABLES, REFERENCES, SELECT, SHOW VIEW, TRIGGER, UPDATE ON `csp_ytic`.* TO 'csp_ytic'#'localhost' WITH GRANT OPTION;
So with this, I added the user with all the privileges.
After this I revoke the privileges in my table.
REVOKE ALTER, CREATE, CREATE VIEW, DELETE, DROP, INDEX, INSERT, REFERENCES, SHOW VIEW, TRIGGER, UPDATE ON `csp_ytic`.`tag_scanned` FROM 'csp_ytic'#'localhost';
I thought it's enough.
But when I run my script with this user, I can SELECT, INSERT, UPDATE, and DELETE.
What am I doing wrong?
I talked to the developer of HeidiSQL about it and he told me I can query it by "show grants" command of sql, but i don't understand the result set coming from it.
show grants // I execute query here
GRANT USAGE ON . TO 'fsdb1user1'#'%' IDENTIFIED BY PASSWORD
'something'
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP,
REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON
fsdb1.* TO 'fsdb1user1'#'%'
mysql documentation says
SHOW GRANTS displays only the privileges granted explicitly to the
named account. Other privileges might be available to the account, but
they are not displayed. For example, if an anonymous account exists,
the named account might be able to use its privileges, but SHOW GRANTS
will not display them.
I think there might be some software somewhere trying some queries and checks grants that way.
It appears that this user is allowed to do a lot. Here is actually a good reference on all of these http://dev.mysql.com/doc/refman/5.1/en/grant.html#grant-privileges.
The user in question can run SELECT, UPDATE, and DELETE queries. They can CREATE tables and databases. They can DROP tables, databases, and views. They can create and alter INDEXes. They can ALTER table structures. They can use CREATE TEMPORARY TABLE. And finally, they can LOCK TABLES that they have SELECT privileges on. In this case, the user can do this on any table in this database (fsdb1) and from any host.
grant LOCK TABLES, SELECT,ALTER,INSERT,CREATE ON `databasetoupgrade%`.* to 'someuser'#'localhost';
those are the privileges I gave a users that needs to be able to ALTER a table (add columns, ...)
the mysql documentation states that alter, insert, create is needed, but even with lock tables and select permissions, I still get the error that the user does not have enough permissions to do ALTER.
When I give the user all privileges on those tables/databases is works.
Does anyone know what the EXACT privileges are that I need to do ALTER? Of which one did I forget in the list above?
This post can be closed, this fixed it:
grant ALTER, LOCK TABLES, SELECT, INSERT, CREATE
I might have screwed up somewhere in my previous commands...
These grants now work fine (for backups) + ALTER command:
grant ALTER, LOCK TABLES, SELECT, INSERT, CREATE