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.
Related
I have only seen examples of SQL statements granting users access to one database in a Postgres cluster at a time. Is there a way to grant a non-superuser access to all databases and their tables including future databases that get created in the cluster?
Since PostgreSQL v14, this is fairly easy, and you can use the following SQL script:
-- exempt the user from row level security
ALTER ROLE seeall BYPASSRLS;
-- allow the user to read all data
GRANT read_all_data TO seeall;
If you want write access as well, there is also a predefined role pg_write_all_data.
This relies on the fact that by default, everybody has the CONNECT privilege on databases. Of course you also have to configure pg_hba.conf to allow access.
And in case you wonder: no, before v14 you have to grant access to all objects individually. Group roles help with that.
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.
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 have created several new tables on a new database(Microsoft SQL server 2005). Now those tables are ready for client users to view through Access 2003 by using System DSN ODBC object (with SQL authentication). What I did was to create a Role and a schema in the database, and a login user for my SQL server default with my database and the schema name.
The problem is that clients not only can see tables I created but also system view objects in the database. I am not sure what should I do to setup a SQL login user, a schema and a role so that only my tables will be visible? Not sure why system view objects are visible to login users by default.
Another alternative way to clean up permissions I have right now. I did check some system view objects (a very long list). They all have permission with the schema I created some with public schema. Is there any way by using T-SQL script to view and then to delete permission associated with my schema for those system view objects? After that, I need to use similar scripts to add permission with my schema to the tables I created.
Well, by default, a new user will also be member of the "public" server and database role. The objects in the sys. and INFORMATION_SCHEMA schemas are visible to members of the public role.
You can either explicitly deny your own role access to those schemas, or you could remove the public role from your login user.
Marc