I would like to create a role connected as SYSTEM. But because I have a lot of schemas with a lot of roles and all of them will be created this way, I don't want the created roles to be granted to SYSTEM (otherwise it eventually will exceed the 148-roles limit).
=> Is that possible to disable the automatic grant on the creator?
NB: for now I work on Oracle 9i but it will soon be upgraded to 11g
There are 2 parts to my answer:
Roles in Oracle are a bit like keys on your keyring: just because they're on the keyring doesn't mean your using them all the time. Oracle has the concept of default roles: these roles are activated automatically when the session is created. The other roles can be enabled later if the user so desires.
The 148 role limit applies to active roles, see for example this documentation link for oracle 10g: http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_6012.htm#sthref7227
To disable roles from being default, use ALTER USER ... DEFAULT ROLE ..., see http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4003.htm#sthref5717
Don't create any objects, even roles, when connected as SYSTEM. Instead you should be using an ordinary user to create a role and adding objects to it that is appropriate for that user's schema's objects. You will need to grant the CREATE ROLE system privilege to those users that need to own objects and have roles for them, but that's all part of the Oracle security model.
The maximum number of user-defined roles that can be enabled for a
single user at one time is 148.
You can pretty much create as many roles as you like - just don't enable them all at once.
When you create a role (other than a user role), it is granted to you
implicitly and added as a default role. You receive an error at login
if you have more than MAX_ENABLED_ROLES. You can avoid this error by
altering the user's default roles to be less than MAX_ENABLED_ROLES.
Thus, you should change the DEFAULT ROLE settings of SYS and SYSTEM
before creating user roles.
http://docs.oracle.com/cd/B10500_01/server.920/a96521/privs.htm#15539
e.g.
ALTER USER SYSTEM DEFAULT ROLE DBA
Related
I have a database and want to give out roles and privileges.
My aim is to allow multiple users - all have the same privileges - to be able to create, edit and view the tables (That's it).
I understand there are user table privileges that allow a user to Create, alter, drop and delete items in tables. But I also understand that there is a
resource user pre-defined role that allows a user to do the same thing.
Would I offer both of the roles? The table-level privileges and predefined roles? What would happen if I do offer both? Can I?
That is more a database administration question, as you have users that develop their own tables. And the heart of your question, "one size fits all prepacked" role RESOURCE or better a bespoke solution for your set of users is really one of administrative style, taste, and your special case.
Personally, I don't like the role RESOURCE as it lacks the privilege CREATE VIEW.
Please note that the privilege CREATE TABLE (granted directly or via a role) allows the user to create tables in his/her own schema. To create tables in other schemas (or "all the tables on the database"), you need the privilege CREATE ANY TABLE. See documentation for details.
I'm using Firebird 2.5 and want to log on with Windows Trusted authentication which works fine. However I want each windows user to be allocated a specific role for the database they are logging into. I have defined my roles in the database but don't know how to allocate the role to the windows user. I thought if I added a user with the same windows name in the security database and assigned them a role that would work, but apparently not. Any help would be appreciated
The only way in Firebird 2.5 and earlier to use a role, is to explicitly specify it on connect in the isc_dpb_sql_role_name connection property (or equivalent), assuming that the user has been granted the role. There is one exception introduced in Firebird 2.5, and that is 'auto admin mapping' which automatically enables the RDB$ADMIN role for administrator users.
In Firebird 3 you can create custom mappings which allow you to map specific users to roles. See Mapping of Users to Objects. This documentation suggests it is also possible to map user groups derived from trusted auth to roles or users, but this isn't clearly documented, so I'm not exactly sure how it works.
Firebird 4 will introduce default roles for users, which can be granted as a default role to that user. Default roles will always be enabled for a user.
From the documentation I understood that the schemas are related to one user. I want to create 6 schemas that each will have its tables, but I want just one user that can connect through php and insert some data in those tables (will hace access to the other schemas).
I know you can just assign the CONNECT and RESOURCE roles to those users, but from what i read its not the best option regarding security.
I thought about making 2 roles, one for the schema users and another for the php user.
For the php user: GRANT CREATE SESSION, UNLIMITED TABLESPACE to
For the schema users; but do i need some privileges for these users? Since they will not be accessed
Is this a correct way to do this?
In Oracle each schema is also a user. You can lock users that you do not want people to log in to and then give the user that you want to login privileges on the objects in the other schemas.
Taking a course on Oracle database security, I have learned profiles are being created to restrict access of some users to some resources.On the other hand, we have functions and policies, which can restrict users too, but I cannot clear the difference between these two. Why we use profiles while we can create policies for users?
A Profile restricts how much system resource a user is allowed: how many concurrent sessions they can have, how much CPU they can use, etc. We can also use Profiles for password management: how many failed logins they're allowed, how long a password lasts, etc.
So a Profile defines the broad bounds of system usage. It governs hardware and database access.
By "policy" I assume you mean Fine-Grained Access Control. These policies set limits to what a user can see of an individual table: what rows they can see and what columns. So we could.use FGAC policy to allow a manager to see all the details for their direct reports but only certain information for all other employees.
So a Policy applies further restrictions to a table which a user already has access to. Which highlights the missing P from your question.
A Privilege grants a user permission to do a specific thing. By default a user cannot do anything in a database. They can't even connect to it without the CREATE SESSION privilege. There are two levels of Privilege. A System Privilege allows a user to do general activities like create a table, execute any procedure, query the data dictionary, etc. A Table Privilege allows a user to do something with a specific object owned by a different user, such as select from my.employee_table, execute her.string_function, etc.
So you can see how Privileges and FGAC Policies interact. I might grant you select and update on my.employee_table but enforce a policy that only allows you to update records for department 40.
To summarise. There are four levels of user restrictions.
In descending order of breadth:
Profile
System Privilege
Table (i.e. Object) Privilege
FGAC Policy
Note: 12c introduced some called an Audit Policy. Clearly that is relevant to the general topic of Oracle database security but I don't think it's pertinent here.
So, I need to implement SSO in our Oracle databases (using Standard Edition only) and I'm nearly there but I have one annoying problem.
Here's the basic run down of how the user is created. This all works beautifully and I can connect without usernames or passwords. No error are thrown when I GRANT the role of assign it as default
CREATE USER "OPS$DOMAIN\USER" IDENTIFIED EXTERNALLY;
GRANT create session TO "OPS$DOMAIN\USER";
GRANT my_awesome_role TO "OPS$DOMAIN\USER";
ALTER USER "OPS$DOMAIN\USER" DEFAULT ROLE my_awesome_role;
But when i log in, the role doesn't appear when running
SELECT * FROM session_roles
and I need to specifically run the SET ROLE command to bring it to life
SET ROLE my_awesome_role
So my question is, do I need to do something different with roles when using external authentication in Oracle? The documentation is a little vague, or at least my reading of it is ;-)