I have an SQL Azure database and there are already thousands of objects under the DBO schema.
I want to create a new user with specific access requirements
the requirement is below.
User can only see a few of the objects under the dbo schema
User can make an update/select/alter/execute..etc. any type of modifications, including adding or removing columns from the objects they are allowed to see.
User can add new objects under the dbo schema.
User should not see the objects(which they are not allowed to see) under the dbo schema in the SSMS browser.
Can you help me to setup the user with specification above?
As Dan Guzman said this would be possible without #3. Beacuse "Create table" is only a database level permission, cannot be assigned at the schema level.
A user can be defined as the schema owner. If the user has "Create Table" permissions at the database level and is a schema owner, all tables will be created in the schema he/she owns.
Create login and user in Azure SQL:
use master;
CREATE login user1 with password='SafePassword'
use userDb;
CREATE USER user1 FOR LOGIN user1;
GO
We can use following query to generate grant T-SQL script. Select the tables you want to grant to the user.
SELECT 'GRANT SELECT,INSERT,DELETE,UPDATE ON "' + TABLE_SCHEMA + '"."' + TABLE_NAME + '" TO "user1"' FROM information_schema.tables
Related
I have a PostgreSQL DB user "limited_user" and want to give SELECT permission on one table ONLY.
GRANT CONNECT ON DATABASE "db1" TO limited_user;
GRANT SELECT ON TABLE users to limited_user;
What happens is that when I try \dt , the user can see all the other tables in this db1, while he can perform SELECT operation to table "user" as I gave permission. How can I revoke access access to the user so that he can not see other tables and just one table?
You can't, at least not in any straightforward way that I am aware of.
Tables exist within the schema namespace, and schemas exist within the database. To give access to a user on a particular table means you must also give that user the USAGE permission on the schema to which the table belongs. USAGE does not grant permissions on the tables themselves, only the the schema in question. But table definitions are part of the schema, so USAGE does allow the user to see table names (and the columns too).
But if there are other tables in the same schema, the user will not be able to SELECT from those tables unless you also GRANT SELECT on those tables, even though they will be able to see that they exist.
This answer gives a pretty clear explanation of the permission system.
Edit to add:
One way to achieve a similar outcome would be like this (using psql):
sec_schema=# REVOKE ALL ON ALL TABLES IN SCHEMA sec_schema FROM restricted_user;
REVOKE
sec_schema=# REVOKE USAGE ON SCHEMA sec_schema FROM restricted_user;
REVOKE
sec_schema=# CREATE SCHEMA new_schema;
CREATE SCHEMA
sec_schema=# GRANT USAGE ON new_schema TO restricted_user;
GRANT
sec_schema=# CREATE VIEW new_schema.secret_view AS SELECT * from sec_schema.secret_table;
CREATE VIEW
sec_schema=# GRANT SELECT ON new_schema.secret_view TO restricted_user;
GRANT
This will remove all access to the schema sec_schema for user restricted_user, but then creates new_schema and new_schema.secret_view which is a cover view over sec_schema.secret_table. After the GRANT SELECT, the user will be able to read the data from table sec_schema.secret_table through the view, but they will not be able to see any objects in sec_schema.
I have a Sybase database and I've created a user following this video. Now I want to grant only select and get DDL permissions to the user, I've granted select permissions on all the user tables in the database to the user using grant select on tableName to user_ro query. But I'm not able to identify which permission will allow user to get DDL of all the database objects and can only read the data. What are the least privileges or roles that are needed to be granted to the user?
Queries that I ran against the database using SQL Interactive board:
//create login under master
use master
sp_addlogin user_ro, user1234
//verify user is created successfully
select name from syslogins
//add login user to mydatabase
use mydatabase
sp_adduser user_ro
//grant select on all tables one by one
grant select on tableName to user_ro
I'm quite new to Sybase, so please correct me wherever I'm wrong.
There is no specific DDL permission in ASE.
All programs that make DDL just select from system tables the definition of a certain object. So if you have access to some database and sp_help works then you can also create DDL from an object.
Following code recreates a user:
-- Remove link to order schema
ALTER AUTHORIZATION ON SCHEMA::order TO dbo
-- Recreate order user without login
DROP USER order
CREATE USER order WITH DEFAULT_SCHEMA = order
-- Restore link to order schema
ALTER AUTHORIZATION ON SCHEMA::order TO order
My question is, why do we need to remove link to schema before dropping a user, and restore it back after user created?
The behavior of Schemas changed in SQL Server 2005. Schemas are no longer equivalent to database users; each schema is now a distinct namespace that exists independently of the database user who created it. In other words, a schema is simply a container of objects. A schema can be owned by any user, and its ownership is transferable.
https://msdn.microsoft.com/en-us/library/ms190387.aspx
http://basitaalishan.com/2014/05/29/the-database-principal-owns-a-schema-in-the-database-and-cannot-be-dropped/
Ok, just found why we need to temporary move the schema link to another owner before deleting a user.
It will return error if not doing so:
The database principal owns a schema in the database, and cannot be dropped.
I've the following view defined into myCustomDatabase:
CREATE VIEW myCustomDatabase.dbo.myView AS
SELECT job_id FROM msdb.dbo.sysjobhistory
myCustomDatabase's owner is sa.
My current user (called currentUser) has only the db_reader role on the myCustomDatabase.
guest is enable on msdb database.
When I execute the view I get the following error:
The SELECT permission was denied on the object 'sysjobhistory', database 'msdb', schema 'dbo'.
I understand that my current user has no role defined on the system database.
Which role/authorization should I give to my current user to allow him to execute the view (which contains only one column of the system's one), but not give to him full access to the table.
To resume the following view should work when called with currentUser:
CREATE VIEW myCustomDatabase.dbo.myView AS
SELECT job_id FROM msdb.dbo.sysjobhistory
, but not the following query:
SELECT * FROM msdb.dbo.sysjobhistory
Edit : viewable tables in MSDB
Edit2 : My SQLServer version is 2008
You don't need to grant permissions on the tables referenced by the view as long as the ownership chain is unbroken. In the case of dbo-owned objects in different databases, this requires that:
both databases have the DB_CHAINING option turned on (on by default
in msdb)
databases have the same owner ('sa' is the default owner of msdb)
the user has a security context in the other database (guest is
enabled by default in msdb)
Consequently, the following script should do the job.
ALTER DATABASE myCustomDatabase SET DB_CHAINING ON;
ALTER AUTHORIZATION ON DATABASE::myCustomDatabase TO sa;
Note that you should enable DB_CHAINING in sa-owned databases only if you trust privileged users with permissions to create dbo-owned objects. This isn't a consideration if only sysadmin role members can create objects anyway. Also, if the old owner is not a sysadmin role member and you need that login to retain dbo permissions, add the old owner as a regular database user and add to the db_owner role.
In Microsoft SQL Server, I have a schema XXX.
Q: How do I create a user XXX such that issuing the following command:
SELECT * FROM Table
is the same as
SELECT * FROM XXX.Table
Here's what I have so far:
CREATE SCHEMA XXX authorization dbo -- I think
CREATE LOGIN XXX
WITH PASSWORD = '123';
CREATE USER ItDontMatter FOR LOGIN XXX
WITH DEFAULT_SCHEMA = XXX;
Correct.
The DEFAULT_SCHEMA option is what you use
Specifies the first schema that will be searched by the server when it resolves the names of objects for this database user.
and
If DEFAULT_SCHEMA is left undefined, the database user will use dbo as its default schema. DEFAULT_SCHEMA can be set to a schema that does not currently exist in the database. DEFAULT_SCHEMA can be set before the schema that it points to is created.
As a small note to gbn's answer, the two are never exactly the same. If you do not specify the table owner, SQL Server will not cache your query because it's not sure about access rights. So for performance, always specify schema.table in your queries, procedures, functions and views.