We have in our DB a Table which contains a dozens of rows.
The only DML's which applied on the Table are :
1.Inserts - Rows are inserted due to Trigger execution on another table .
2.Deletes - A schedualed procedure is loading requested records to temp table, working with these records and afterwards deleting them from the specific table (there is also a SELECT from the table in order to populate the temp table each time the procedure is running).
We've build the Table with PK and when we run the deletion,
the table is deleted row by row with the ID of the PK column.
just to clarify, we dont have any UPDATES opreations on the table .
Is there any specific guidelines or recommendations when creating such a table ( without updates ) ?
Thx for your answers .
There's nothing special about a table that you don't intend to update.
You could, if you wanted for security reasons, deny update permissions to everyone, since you really only want to allow inserts, deletes, and selects, but there's nothing special about the design, and nothing forcing you to do so.
you can create this table in another schema and grant select, insert, delete to your schema without granting update
so any trying to execute update statemets from your current schema will not executed.
here is an example:
connect system/manager
grant connect, resource to user1 identified by user1;
grant connect, resource to user2 identified by user2;
disconnect
connect user1/user1
create table user1.table1(col1 number, col1_desc varchar2(16));
grant select, insert, delete on user1.table1 to user2;
disconnect
conn user2/user2
select * from user1.table1
insert into user1.table1 values (1, 'insert-user2');
commit;
insert into user1.table1 values (2, 'insert-user2');
commit;
delete from user1.table1 t where t.col1 = 2;
commit;
update user1.table1 t set t.col1_desc = 'ins-user2' where t.col1 = 1;
commit;
-- last update statement will throw ORA-01031: insufficient privileges
note: you can use table1 table name directly from user2 by using synonym for user1.table1
regards,
Related
I allowed user to input SQL statement in the system
But there are some data that i want to hide from user
Is there any way that i can disable INSERT or SELECT or UPDATE or DELETE statement on selected TABLE?
Use:
REVOKE privileges ON object FROM user;
For example:
REVOKE ALL ON employees FROM anderson;
REVOKE INSERT ON employees FROM anderson;
I'm creating a table with a superuser (admin), and trying to GRANT ALL and change the owner of a table.
I'm running the following statements in Redshift, where (non-superuser) john is a member of the developers group (and only a member of the developers group):
GRANT ALL ON users.addresses TO GROUP developers;
ALTER TABLE users.addresses OWNER TO john;
I've confirmed that user john has select/insert/delete/update permissions on users.addresses, and is the owner of the table. I've also confirmed that user john has USAGE on the users schema.
However, when I log in as john, the table simply does not appear. When I try a SELECT * FROM users.addresses, Redshift says that the table does not exist.
What am I missing here? Is there an extra layer of permissions or security in Redshift that I'm not seeing? I've looked through the documentation, but haven't had much luck so far.
Because Redshift is saying that the table doesn't exist, that points towards the CREATE TABLE not being committed to the database when you're running it as a superuser account. If you disconnect as the superuser account and then reconnect and attempt to run the SELECT statement against the table, do you get the same error?
Try running an explicit COMMIT statement after you create the table, and then attempt querying it using the non-superuser account. If the client you are using is wrapping all query executions inside of a transaction block, it is possible that they aren't being committed prior to you connecting with the non-superuser account.
Also for reference, I ran the following queries with auto-commit enabled and was unable to replicate the issue you're describing:
-- Run as superuser account:
CREATE SCHEMA users;
CREATE TABLE users.addresses (
user_id VARCHAR(8) ,
user_address VARCHAR(512)
);
INSERT INTO users.addresses VALUES ('12345678', 'Address 1');
CREATE USER john WITH PASSWORD '********';
CREATE GROUP developers;
GRANT USAGE ON SCHEMA users TO GROUP developers;
ALTER GROUP developers ADD USER john;
GRANT ALL ON users.addresses TO GROUP developers;
ALTER TABLE users.addresses OWNER TO john;
-- Run as non-superuser account 'john':
SELECT *
FROM users.addresses;
-- Result Set:
-- user_id user_address
-- 12345678 Address 1
Users have create table statement with select statement from multiple tables from multiple schema. I want to restrict them to read data and allow them to create empty table in their schema with metadata only not data. This I want to do at user access and roles level.
Please tell me how I can do this?
I have tried giving them read access on underlying tables but users can see data as well.
Create table cust_acct_details
as
select *
from ep_rel.acct a
inner join ep_dnf.Cust_account ca
on a.acct_id = ca.acct_id
Tables should create without data.
Add below condition to your code
-- condition to add where 1<>1
Create table cust_acct_details
as
select *
from ep_rel.acct a
inner join ep_dnf.Cust_account ca
on a.acct_id = ca.acct_id
where 1<>1
Please make sure there are unique column names in your select statement. Oracle will not allow same column name in one table. Please use alias instead of *.
If you remove all tablespace privileges from a user they can still create tables but they won't be able to populate them.
For example, if you run this PL/SQL block to revoke all tablespace quotas from one user:
begin
for users in
(
select 'alter user '||username||' quota 0 on '||tablespace_name v_sql
from dba_ts_quotas
where username = 'TEST_USER'
order by 1
) loop
execute immediate users.v_sql;
end loop;
end;
/
Now the user can create tables but will get an error if they try to add rows:
SQL> create table test1(a number);
Table created.
SQL> insert into test1 values(1);
insert into test1 values(1)
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace 'USERS'
For metadata, users can always see the metadata in their own schema. To allow them to view the metadata in other schema, run a grant like:
grant select_catalog_role to the_user;
Then that user can view the metadata either in the ALL_ data dictionary views, or using DBMS_METADATA.GET_DDL.
Is it possible to mark a column immutable in MSSQL?
Seems like it would be a useful DDL feature; once a value is set in a row ('row' being defined as a specific relation of values to a primary key), it could not be changed without deletion of the row.
Obviously (like most things) this is more than doable in the application layer, but half the fun of SQL DDL is error-checking your application code.
If the user doing the DML is not the owner of the objects and not "db_owner" in the database itself, you can just grant "insert" privilege, but not update privilege for that table:
Assuming a table with id, col1, col2
grant insert, select, delete on the_table to the_user;
grant update (id, col2) on the_table to the_user;
With these grants the_user can insert rows and supply values for all three columns. He can also update the id and the col2 column, but not the col1 column.
The db_owner (and possibly the creator/owner of the table) can always update all columns. I don't know if there is a way to revoke that privilege from those rolws.
It's possible, using an UPDATE TRIGGER like this:
CREATE TRIGGER trgAfterUpdateAsset ON dbo.Asset
FOR UPDATE AS
IF UPDATE(AssetTypeID) AND EXISTS (SELECT * FROM inserted i JOIN deleted d ON i.ID = d.ID WHERE i.AssetTypeID <> d.AssetTypeID)
BEGIN
RAISERROR ('AssetTypeID cannot change.', 16, 1);
ROLLBACK TRAN
END
(Note: The table has a Primary Key column, called ID).
I'm only rejecting the update if the value of AssetTypeID changes. So the column could be present in an update, and if it specified the old value, than it would pass through. (I needed this way)
No, there is no such feature in SQL Server.
The closest I can think about is an update trigger on the table that checks if the values in the specific column are the same for the INSERTED and DELETED logical tables and rejects the updates for the changed rows.
To my knowledge, this is not possible with DDL. However, you could implement BEFORE UPDATE triggers to meet your requirement. In the BEFORE UPDATE trigger, you could raise an exception or do whatever you want rather than update the row.
Another approach is to deny update rights to the table and create a stored procedure (which users do have the right to execute) that does not update the immutable field.
I just created two tables and they are named as tblA and tblB. I also created a user(Security/Login) who will be used for a remote insert/update.
What is the best way to permit this user to access for only those two table out of 50 table. I have tried look for the way from (Security/Login) and (Database/Properties). Can I limit it from user account level?
Use a 'grant' statement:
grant select on tblA to the_user_name
grant insert on tblA to the_user_name
grant update on tblA to the_user_name