I am looking for the best way to setup an Oracle database so that multiple roles can share a single schema with tables.
I would have, for example, several roles:
Application User
N Developer Users
DBA User
... future user types
I have been able to create groups, grant privileges to other schemas, and create a logon trigger to switch the schema on logon. However, users are not able to view tables through SQL Developer.
SQL Developer will only show the objects owned by the current user, not those that are owned by the session's current_schema setting, in the tree view unless you go to Other Users and choose the schema you're interested in. In order to see objects owned by other users, you're realistically going to have to navigate to the appropriate schema. If there are a large number of schemas in the database, you can right click on Other Users and create a filter that limits the set of users that are returned to just the schema you care about.
Related
I have a front application, where i can jump in to that database. now i want to create a database for the server because one server can have many databases, so if i am in that selected database called as abc, i can go ahead and create a another databse babyabc, but want that this babyabc should have all permissions and login information of the parent abc database.
is it possible to do in sql server, if yes how can i do it
for creating a database, i can do always as:
create database babyabc
Database Permissions are set at the database level. If you have two similar databases, you need to create the appropriate USER, ROLEs, etc in both of them.
If you have some which are needed on every database, and don't have permissions specific to User objects (which differ), you can create and set the permissions in the model database. Then any databases created after you've made those changes to the model database will have those permissions.
For example, you might have an AD group that you automatically want to be on the database, and have the db_datareader role. So you would do:
USE model;
GO
CREATE USER [StackOverflow\RegisteredUsers];
GO
ALTER ROLE db_datareader ADD MEMBER [StackOverflow\RegisteredUsers];
GO
Then, if you create a new database, that user will be in the new database, and have the db_datareader role.
I am not so into SQL Server and I have the following doubt: I have to require the creation of an user that can work on some databases. This user have to create\delete table, insert\delete records in these tables.
What type of permission have to be set for this user on these databases? Is dbowner ok to perform these operations? (in particular is very important that this user can create\delete tables) or am I missing something?
Just to understand first the benefits of using roles :
Roles are a part of the tiered security model:
Login security—Connecting to the server
Database security—Getting access to the database
Database objects—Getting access to individual database objects and
data**
Predefined database roles
You may need to create your own, but you have access to several predefined database roles:
db_owner: Members have full access.
db_accessadmin: Members can manage Windows groups and SQL Server
logins.
db_datareader: Members can read all data.
db_datawriter: Members can add, delete, or modify data in the tables.
db_ddladmin: allows a user to create, drop, or modify any objects within a database, regardless of who owns.
db_securityadmin: Members can modify role membership and manage
permissions.
db_bckupoperator: Members can back up the database.
db_denydatareader: Members can’t view data within the database.
db_denydatawriter: Members can’t change or delete data in tables or
views.
Fixed roles :
The fixed server roles are applied serverwide, and there are several predefined server roles:
SysAdmin: Any member can perform any action on the server.
ServerAdmin: Any member can set configuration options on the server.
SetupAdmin: Any member can manage linked servers and SQL Server
startup options and tasks.
Security Admin: Any member can manage server security.
ProcessAdmin: Any member can kill processes running on SQL Server.
DbCreator: Any member can create, alter, drop, and restore databases.
DiskAdmin: Any member can manage SQL Server disk files.
BulkAdmin: Any member can run the bulk insert command.
From the SQL Documentation:
Members of the db_owner fixed database role can perform all
configuration and maintenance activities on the database, and can also
drop the database in SQL Server.
Are you certain that is the right that you want to grant this user? It seems like a more restricted set of permissions would be more suitable for them.
For example, the roles db_ddladmin, db_datareader, and db_datawriter could be more suitable:
db_ddladmin:
Members of the db_ddladmin fixed database role can run any Data
Definition Language (DDL) command in a database.
db_datareader:
Members of the db_datareader fixed database role can read all data
from all user tables.
db_datawriter:
Members of the db_datawriter fixed database role can add, delete, or
change data in all user tables.
Alternatively, you can grant specific privileges to the user account against that database and it's user objects in order to restrict their access to the functionality subset you want.
As per my understanding each database user is assigned a role. Each role owns a certain schema. The point of role then is to determine which schema a database user has access to.
Why not just remove the role and associate users directly with schemas?
Roles do not only manage the permissions at schema level. Roles are combinations of priviliege, that provide many other levels of control such as which user can access which database object (tables, procedures, ...), what type of queries it may execute (select, update, delete, insert), and so on.
Bottom line, roles give a flexible, fine-grained control over the way users access and use the database.
For more information see the sql-server documentation.
I am trying to keep my school works under one user account. Currently I am making a new database user for every lab session. Surely this is not the right way to go?
I want to create a another schema, alongside my existing schema.
NB. I see a dropdown option for schema in the SQL workshop. So there might be a option to create multiple schema. But I can't find how to do it. The google links all say I have to create a new user.
In Oracle user is owner of its schema. User is an account that can access database. It depends on grants if it can access only own schema or more schemas.
When you create user you create schema. You can't create just a schema and assign it to existing user. However you can create new user with schema and grant other users access to newly created schema. In your case if you want new schema for each lab you need to create user for each lab and then grant privileges to your main user.
Here you can find some explanations:
Difference between a user and a schema in Oracle?
Microsoft's docs on schema ownership don't go beyond saying "Schemas can be owned by any database principal, and a single principal can own multiple schemas." (MSDN doc)
I get that schemas are a way of containing different security permissions, but what is the purpose of assigning an owner to a schema and what special privileges does that user who owns the schema receive as opposed to simply being a member of the schema?
An owner of a schema is like the sysadmin within that schema, can create , drop, select , update, delete , alter objects, give permissions to other users , revoker permissions of other users and pretty much everything .
On the other hand a user with in a schema can only do the operations according to what database role was given to them , for example will be assigned these permission as Permission to create objects, db_datareader can only issue select statements against tables, db_datawriter can do inserts/updates and the list goes on.
You dont want every user who has access to database to do all sorts of operations, some people will have less access some will requires more access, hence the different roles to suit user specific needs.
Ownership of schema has it roots with the problem we had in past before sql server 2005 when there were no schemas and objects were owned by users. To separate users from objects schemas were introduced and the concept of "Schema Ownership" was introduced, it is just another way of saying that this user has all the permissions in a schema.