July 8th, 2009

Data Control Language, GRANT SELECT, INSERT, UPDATE, and/or DELETE

Posted by admin in R. Data Control Language
Format:   GRANT {SELECT | INSERT | UPDATE | DELETE | REFERENCES} [column_names]
             ON {table_name | view_name}
             TO {user_id | PUBLIC} [WITH GRANT OPTIONS];

When you create a database object, you own it and you are the only person who can grant privileges to others. When you grant privileges to them, they can use those privileges, but they can not grant those privileges to others. This allows you to give users access to objects, but they can not give access to other users.

If you limit the GRANT to specific column_names, this option normally applies only to the INSERT and UPDATE privileges. You limit the ability to SELECT specific columns by creating a VIEW with the specific columns and then GRANT SELECT on that VIEW.
> SQL Server and Sybase do allow specific column_names to be specified in the SELECT, allowing you to define fewer views.

> Many RDBMS systems use a GRANT similar to DB2′s format, which allows you to specify a list of tables and a list of user-IDs. This makes it easier to grant many privileges at once.

July 6th, 2009

Data Control Language, GRANT

Posted by admin in R. Data Control Language

The Data Control Language is for data security and has four commands: GRANT, REVOKE, COMMIT, and ROLLBACK.The first line of security is the users for whom you GRANT or REVOKE access and update privileges to your data. Some people should never have access to your data while others should have only restricted access. Some people can only see certain data while others have the right to update that data. Only someone like your Database Administrator (DBA) and the owner of the company should have access to all the data.

If you create a schema, you are designated as the owner of that schema. As the owner of the schema, you can grant access privileges to other users. All privileges are withheld until they are explicitly granted by you. A users must go through an authorization process to prove their identity before they can perform the functions you have authorized. You can revoke any privileges you have previously granted.
If you GRANT use of the SELECT command, a user can see a database object such as a table or view.

If you GRANT use of the INSERT command, a user can add table rows.

If you GRANT use of the UPDATE command, a user can modify table rows.

If you GRANT use of the DELETE command, a user can delete table rows.

If you GRANT use of the REFERENCES command, a user can see data where SELECT has been granted to a table and that table references another table.

If you GRANT use of the USAGE command, a user can allow or disallow use of domains, user-defined character sets, collating sequences, and translations.

If you GRANT the ALL command, you are granting all privileges to this user.
You can REVOKE any of these privileges from users.

COMMIT and ROLLBACK make changes permanent or reverse the changes.

July 3rd, 2009

Data Control Language, Ownership of Objects

Posted by admin in R. Data Control Language

When you create a table with a CREATE TABLE statement, you become the owner of that table and you have full privileges for the table (such as SELECT, INSERT, UPDATE, DELETE, GRANT, REVOKE, etc.). Nobody else has any privileges on your newly created table. If others are to be given access to the table, you must explicitly grant privileges to them using the GRANT statement.When you create a view with a CREATE VIEW statement, you own the view, but you can not create the view unless you already have SELECT privileges on all source tables for the view. Since you already have SELECT privileges on the view source tables, you now have SELECT privileges on the view you created. You do not have INSERT, UPDATE, and DELETE privileges for the view you created unless you have previously been granted INSERT, UPDATE, and DELETE privileges for the source tables of your view.

SELECT privileges on a VIEW can be granted to others without giving them any privileges on the source tables of the VIEW. You can effectively limit the columns and/or rows in the view for security reasons, denying other users access to the source table columns and rows. A view can also combine columns from two or more source tables, making the columns appear to be in one table.

If a user must be able to update data in a VIEW, then that user must be given INSERT, UPDATE, and/or DELETE privileges to the source tables for the VIEW.

« Previous PageNext Page »