I have an oracle database with two roles assigned to the same user.
The user will connect from .Net application.
Since each role has its own privileges I would like, when using my application, only one role to be considered. So the user will choose the role to be considered when logging to the application. And the privileges related to the other role wont be "active".
for example
Role 1 can access Table A
Role 2 can access Table B
So theoretically The user can access A & B
When using my application :
Choose either 1 or 2
if 1, show only A table
if 2, show only B table
Is that possible please ?
Thank you
Use of ROLES is one way:
CREATE ROLE roleA;
CREATE ROLE roleB;
GRANT SELECT ON tableA to roleA;
GRANT SELECT ON tableB to roleB;
GRANT roleA to TheUser;
GRANT roleB to TheUser;
When the user chooses a role in your application, issue the appropriate SET ROLE command:
User chooses 1:
SET ROLE roleA;
Otherwise,
SET ROLE roleB;
Since the roles are not defaults, they will only be active via the SET ROLE command. You can password protect the roles, too.
Related
create role aaaaa_min_access_role;
grant role aaaaa_min_access_role to user me;
use role aaaaa_min_access_role;
show grants to role aaaaa_min_access_role;
show databases;
it results in 3 databases being outputted, the owner of those is accountadmin
wondering how?
when i do
REVOKE USAGE ON DATABASE DB_TEST FROM ROLE aaaaa_min_access_role;
REVOKE USAGE ON SCHEMA DB_TEST.SCHEMA FROM ROLE aaaaa_min_access_role;
REVOKE SELECT ON ALL TABLES IN SCHEMA DB_TEST.SCHEMA FROM ROLE aaaaa_min_access_role;
it results in 0 objects being impacted. I'm able to execute select * from DB_TEST.SCHEMA.Table1 successfully
Unless specified otherwise, new roles inherit from the PUBLIC role.
PUBLIC
Pseudo-role that is automatically granted to every user and every role in your account.
https://docs.snowflake.com/en/user-guide/security-access-control-overview.html#system-defined-roles
So the new role probably had at least some access to these databases through the PUBLIC role. You can check that by revoking the PUBLIC role from the new role you created.
I am trying to create a group that has the right to create databases and roles. And then inherit these privileges with the next role. But the error constantly pops up that I don't have rights
Edited: (mistake between 'gg' and 'ggc', but steel doesn't work)
create role ggc with createdb createrole;
create user gg login password 'gg';
grant ggс to gg;
Always get this error: "SQL Error [42501]"
This way is also doesn't work
CREATE ROLE qwe WITH NOLOGIN CREATEDB CREATEROLE;
CREATE ROLE ads WITH LOGIN PASSWORD 'pass';
GRANT qwe TO ads;
SET ROLE ads;
CREATE DATABASE test;
This behavior is normal and is actually documented here:
The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actually SET ROLE to a specific role having one of these attributes in order to make use of the attribute. Continuing the above example, we might choose to grant CREATEDB and CREATEROLE to the admin role. Then a session connecting as role joe would not have these privileges immediately, only after doing SET ROLE admin.
You grant roles to users, not the other way round
I need to run queries as a "user" which is a record in a table, with permissions based on a record value of that user.
I have a database with a tUsers Table, such as:
ID Username Email Role
1 Pieman mail.com Admin
2 Cakedude mail.co.uk Receptionist
3 Muffin gh.com Other
I need to have it so only "users"/records with "Role" of "Admin" can view and edit the table, and "Receptionist" view it etc.
I know of and use GRANT for permissions, but don't know how to run a query as a user based on a table record and to have the permission only GRANTED if that users' role is "Admin"
So if I have:
USE DB1;
GRANT SELECT ON OBJECT::tUsers TO Admins;
GO
SELECT * FROM tUsers
How do I make that run as say tUser with ID 1, and the GRANT if the users' role = "Admin"
I'm sure I've seen this done before.
I'm fairly new and still learning the correct terminology, so if this is a duplicate question, or is essentially just describing an sql Function sorry.
I don't think you can grant or revoke permissions to users in your own user table. However you can of course restrict queries based on your own user table.
One solution is to do it in your application. Verifier permissions before you do anything for him/her.
Another solution is to use stored procedures which take user id as parameter and do the checking for you in a central place.
The third one is to user parameterized views where you filter out entries one user can't access.
There are other solutions but the basic idea is you need somehow check permissions instead asking dBm server to do it for you.
I'm a bit confused about permissions in SQL
I have created a medical database.
As a script I'm creating a doctor role and I want to say they can perform updates on tables 1,2 and 3.
The database though actually contains 5 tables.
does it mean that they wont be able to update 4 and 5 ?
or will i have to explicitly say deny update on tables 4 and 5 for the doctor role ?
SQL-Server follows the principle of "Least Privilege" -- you must (explicitly) grant permissions.
'does it mean that they wont be able to update 4 and 5 ?'
If your users in the doctor role are only in the doctor role, then yes.
However, if those users are also in other roles (namely, other roles that do have access to 4 & 5), then no.
More Information: http://msdn.microsoft.com/en-us/library/bb669084%28v=vs.110%29.aspx
Unless the role was made dbo, db_owner or db_datawriter, it won't have permission to edit any data. If you want to grant full edit permissions to a single table, do this:
GRANT ALL ON table1 TO doctor
Users in that role will have no permissions whatsoever to other tables (not even read).
USE DataBaseName;
GO
--------- CREATE ROLE ---------
CREATE ROLE Doctors ;
GO
---- Assign Role To users -------
CREATE USER [Username] FOR LOGIN [Domain\Username]
EXEC sp_addrolemember N'Doctors', N'Username'
----- GRANT Permission to Users Assinged with this Role-----
GRANT ALL ON Table1, Table2, Table3 TO Doctors;
GO
I am trying to setup a new role for making the access rights granting easier. I was wondering if there is an easier way to give select on all tables (newly created tables should be accessible automatically) under a schema to selected users. I ran following queries for the same. But still my user is not able to access the specific table.
CREATE ROLE myrole;
GRANT SELECT ON myschema.mytable TO myrole;
GRANT usage ON schema myschema TO myrole;
CREATE USER mytest1 identified BY '***';
GRANT myrole TO mytest1;
After this, when I login with mytest1 user and trying to run select on myschema.mytable it is asking me to grant usage on schema to user. After I grant usage on schema to user directly it is failing with permission denied for that table.
Please help with the same. I am running on vertica 5.0
Update:
I find that u also have to make that role default or explicitely set that role as default for user session for making the role's effect take place.
ALTER USER mytest1 DEFAULT ROLE myrole;
But still, my another question of how to make all tables under a schema accessible to specific users remains.
As per the Vertica SQL Reference Manual.pdf (page 725) (doc version 5.0 - for page numbers)
GRANT (Schema)
...
USAGE
Allows the user access to the objects contained within the
schema. This allows the user to look up objects within the
schema. Note that the user must also be granted access to the
individual objects. See the GRANT TABLE (page 727) ... .
The the user must also be granted access to the individual objects means that you need to also GRANT table.
The two I use is GRANT SELECT and GRANT REFERENCES which allows the user to run queries and join (reference) tables in the query.
Example:
GRANT SELECT ON TABLE [schema].[Table1] TO myUser;
GRANT SELECT ON TABLE [schema].[Table2] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table1] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table2] TO myUser;
...
6.0 doc reference GRANT SCHEMA (page 808) and GRANT TABLE (page 813).