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.
Related
I am new to HANA Database. I am just trying to create new User in HANA DB through Eclipse systems editor. I have selected only below role as part of user creation.
sap.hana.xs.lm.roles::Developer
But, it is showing below roles as a result of executing query select role_name from "PUBLIC"."EFFECTIVE_ROLES" where USER_NAME = 'TEST_USER';
ROLE_NAME
PUBLIC
sap.hana.xs.lm.roles::Developer
sap.hana.uis.db::SITE_USER
sap.hana.xs.lm.roles::Display
sap.hana.xs.lm.pe.roles::PE_Display
Why being added other roles to user even not selected?
Roles in SAP HANA are collections of privileges and other roles.
This can lead to a situation where a role contains several other roles, each of which can contain other roles and privileges. That way you have a hierarchy of direct and indirect role- and privileges assignments to a user account.
The system view you query is EFFECTIVE_PRIVILEGES. It’s single most important function is to unroll all roles that have been assigned directly and indirectly (effectively going through the roles-privileges-hierarchy) and to return all those assignments.
This “unrolling” of hierarchical structures is not easy/efficient to do in plain SQL, so this system view provides this special feature as a built-in functionality.
The pre-defined role sap.hana.xs.lm.roles::Developer contains several other roles (as your query result shows).
To double-check you can even review the role definition in the HANA XS repository by navigating to thesap.hana.xs.lm.roles package, as this role is delivered as a design-time artefact.
If you actually only want to see the direct assignments of roles/privileges to a user (or to roles), using system views GRANTED_ROLES or GRANTED_PRIVILEGES will get you that.
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.
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.
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.
I want to give access to certain data, in various databases on a single sql instance, to our parent company. They don't want a web service but instead want a stored procedure, which would compile data from different data sources and return a record set.
There is a trust between our two domains so essentially they are on our domain and I will just give the required permissions to sql objects (stored procedures)
I plan to create an 'integration' database which would have the required stored procedures.
While the integration database will have no tables itself, at least for now, I do want to lock the database down so that there are no holes such as the parent company being able to create tables on database or affect permissions etc.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicity give permissions to.
As a sql DBA I make a good .net programmer ie from what I understand it will require the user of commands such as GRANT EXECUTE ON [procedure] TO [user] to grant permissions on selected stored procedures, but beyond this I am not sure of a clear strategy to achieve what I need.
I want to make sure I don't leave holes in the security.
If anyone can advise the steps I need to take, ie what commands I need to run to achieve what I want, or point me to a good article I would appreciate it.
I have already run the command REVOKE CONNECT FROM GUEST on the database.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicitly give permissions to.
Create a role specifically for the users from the parent company
Only grant EXECUTE to the role for the specific store procedure(s)
Grant the role the db_datareader role -- that will make sure they can't create tables, etc.