Anyone have written a stored procedure which can remove all assigned roles/privileges from given user ? I like to do this without looking up each role assigned or privilege assigned.
Similar like below statement but without listing each role and privileges one by one. Removal all roles/privilege in one single statement regardless of what role assigned. This is for user termination process.
CALL REVOKE_ACTIVATED_ROLE('RoleName','username');
Well if you really want the procedure, I'm using this one and it works.
It removes all the granted roles from the user. Run it if you know what you are doing.
create procedure myCleanupUser(in i_user varchar(20)) as
begin
declare cursor Roles for
SELECT ROLE_NAME FROM "PUBLIC"."EFFECTIVE_ROLES"
where USER_NAME=i_user AND GRANTEE_TYPE='USER' AND ROLE_NAME <> 'PUBLIC';
for role as Roles do
call REVOKE_ACTIVATED_ROLE(role.ROLE_NAME,i_user);
end for;
end;
There's no such standard functionality available and I recommend to be very careful with automatically revoking privileges. If the user himself granted privileges that he got granted with ADMIN OPTION or with GRANT OPTION to other users and these privileges get revoked, this leads to a recursive revocation of those granted privileges.
In short: this can become nasty.
For user termination, it's sufficient from a security point of view to disable the logon.
Other than that, it's pretty straight forward to query system view GRANTED_ROLES and GRANTED_PRIVILEGES to generate the REVOKE statements.
Related
I need to create a new firebird-db user which has only access to 4 specific tables. Is there a way to do that?
http://www.destructor.de/firebird/gsec.htm isn't really helpful in that regard.
The - third-party - gsec documentation you link does not provide information about granting rights on tables, because gsec is only for managing users in the security database. In Firebird, rights of users are managed in the individual databases using the GRANT (and REVOKE) statements (it is even possible to grant rights to users that do not exist (yet)). Be aware, Firebird 3 deprecated gsec, and since Firebird 2.5, it is recommended to use the SQL user management statements instead of gsec.
You need to create the user, and then give the user privileges to the tables you want. See the Security chapter in the Firebird 2.5 Language Reference.
A regular, authenticated user has no privileges on any database object
until they are explicitly granted, either to that individual user or
to all users bundled as the user PUBLIC.
Specifically:
Create a user:
create user <username> password '<password>';
See also CREATE USER; to create a user, you need to be either SYSDBA, or you need to have and the admin role in the security database, and the RDB$ADMIN role in the current database, and be logged in specifying the RDB$ADMIN role on connect.
Grant the necessary privileges to the user. For example to give SELECT privileges:
grant select on table <tablename> to user <username>;
To allow select, insert, update and delete:
grant select, insert, update, delete on table <tablename> to user <username>;
See also GRANT; to grant permission to an object, you must be either SYSDBA, the owner of the object, be RDB$ADMIN in the current database, or have been granted the privilege(s) with the WITH GRANT OPTION.
When you need to grant the same set of rights to multiple users, it is better to grant rights to a role, and then grant that role to the users. However in Firebird 3 and earlier, to get the rights granted to a role, the user needs to explicitly specify that role on connect (Firebird 4 will introduce roles that are automatically applied).
I am a big fan of PostgreSQL but can't figure out one aspects of it's built in user management.
My problem is that I have set up pgAdmin and will have some non-developers manually update data in some specific tables. For this reason I have created a new user called "admin" and are looking to restrict this users rights.
I have tried to delete all rights for the user with the following query (from another user):
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM admin;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM admin;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public FROM admin;
The above did lead to the following error when I wrote a simple SELECT statement from the user admin on a table called "crap": ERROR: permission denied for relation crap.
But what I was able to do with the user admin which by now shouldn't have any rights was the following: DROP TABLE crap; which worked!?
I am really surprised by this. This user is not a Postgres superuser. How can I remove this right to drop tables for a specific user?
You're one level off in hierarchy for the permissions.
REVOKE ALL PRIVILEGES FROM SCHEMA public FROM <role_name>;
You were affecting permissions within the table. You must also go one level up to the schema as well to protect create/drop access. You may also want to revoke access at the database level as well to protect the schema.
REVOKE ALL PRIVILEGES FROM DATABASE <database_name> FROM <role_name>;
You could also simply remove the user. Alternatively you could simply disable that user's ability to login.
ALTER ROLE <role_name> SET NOLOGIN;
If these don't work for you, you can go down a somewhat more complicated route and make an event trigger that watches for DROP TABLE events, compares against the role, and either allows it to continue or aborts the transaction.
CREATE OR REPLACE FUNCTION no_admin_drop()
RETURNS event_trigger LANGUAGE plpgsql AS $$
BEGIN
IF CURRENT_USER = 'admin'::regrole THEN
RAISE EXCEPTION 'command is disabled';
END IF;
END;
$$;
CREATE EVENT TRIGGER no_admin_drop ON sql_drop
EXECUTE FUNCTION no_admin_drop();
I would like to know how the privilege SELECT ANY TABLE works internally in Oracle.
Is it treated as a single privilege? Or is it equivalent to make a GRANT SELECT ON MyTable TO MyUser for each table?
As example, I would like to know if this work :
GRANT SELECT ANY TABLE TO PUBLIC;
REVOKE ALL ON MY_TABLE FROM PUBLIC;
Would I still have access to MY_TABLE from any user after those queries?
Yes, all users would still be able to query MY_TABLE.
You are looking at different privilege types:
The main types of user privileges are as follows:
System privileges—A system privilege gives a user the ability to perform a particular action, or to perform an action on any schema objects of a particular type. For example, the system privilege CREATE TABLE permits a user to create tables in the schema associated with that user, and the system privilege CREATE USER permits a user to create database users.
Object privileges—An objectprivilege gives a user the ability to perform a particular action on a specific schema object. Different object privileges are available for different types of schema objects. The privilege to select rows from the EMPLOYEES table or to delete rows from the DEPARTMENTS table are examples of object privileges.
SELECT ANY TABLE is a system privilege that allows the grantee to:
Query tables, views, or materialized views in any schema except SYS. Obtain row locks using a SELECT ... FOR UPDATE.
When you grant that it is a standalone single privilege, visible in dba_sys_privs. When Oracle decides if the user is allowed to access a table it can look first at system privleges, and only goes on to look for specific object privileges (visible in dba_tab_privs) if there isn't a system privilege that allows the action being performed.
System privileges are not translated into individual privileges on each object in the database - maintaining that would be horrible, as creating a new object would have to automatically figure out who should be granted privileges on it based on the system privilege; and it would mean that you couldn't tell the difference between that and individually granted privileges. So, for instance, if you explicitly granted select privs on a specific table, then the user was granted SELECT ANY TABLE, and then they had SELECT ANY TABLE revoked - what happens to the previous explicit grant?
Your scenario is basically the same, except you've specifed all privileges on the object to be revoked. If those are the only two commands involved then PUBLIC has no explicit privileges on MY_TABLE so revoking doesn't really do anything; but if any explicit privileges on that table had been granted then they would be revoked. That has no impact on the higher-level SELECT ANY TABLE system privileg though.
Privileges are cummulative; revoking a privilege on a specific object doesn't block access to that object, it just removes one possible access route.
Incidentally, hopefully you've used a contrived example, as such powerful system privileges should be granted sparingly and only when really needed. Letting any user query any table in your database potentially blows a big hole in the security model. Again from the docs:
Oracle recommends that you only grant the ANY privileges to trusted users
and
Oracle recommends against granting system privileges to PUBLIC.
and read more in the database security guide.
I have created a new user in a MaxDb database. I assign a role that has access to all the tables in roleprivileges but the user can not see these tables.
The user can access the tables if I assign permissions directly to the tables in tableprivileges.
The role has access, other users have this role assigned and they see all the tables.
What can be failing?
Today I've heard of MaxDB for the first time (what an ignoramus, eh?). I'm not sure why you tagged your question with the "Oracle" tag; Google says that MaxDB <> Oracle.
Anyway: it sounds like common problems in Oracle's PL/SQL, where privileges - acquired via roles - won't work, but have to be granted directly to the user.
Saying that "other users have this role assigned and they see all the tables", are you sure that they don't have direct privileges granted as well?
Assuming this deals indeed with MaxDB, and not with Oracle:
In contrast to privileges, roles need to be activated for a user session. Assigning is not enough. It is done by command SET ROLE <role>.
A role may also be activated as default for every new session, with command:
ALTER USER <user> DEFAULT ROLE <role>.
You can also activate all roles assigned to the user, like this:
ALTER USER <user> DEFAULT ROLE ALL.
The Question given in Past Exam was
you need to give academic role the ability to select from, insert
into and modify existing rows in Student table. Anyone given this
Academic role should be able to Pass those privileges to other. write
a query
Create ROLE academic; // I created the role
GRANT SELECT, INSERT, DELETE on student to academic; // Granted privileges
GRANT academic to username; // passed it to user
Will the user have the privileges to pass it to others? If not, how to ?
Use the WITH GRANT OPTION clause at the end of the GRANT statement (the statement granting privileges on the table).
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_9013.htm#i2062455 and scroll down a little bit to the WITH GRANT OPTION heading for documentation.