I have a question about the topic access rights of stored procedures, views and tables.
Users can execute stored procedures and views. If the user needs to update data in a view (this view contains only one base table) do I need to define the usergroup update/insert access rights to the table or view? My intention is, that this usergroup shouldn't have access rights to tables directly.
Can anyone explain me the approach about access rights on stored procedures, views and tables or send me a link with an explanation?
If you grant Insert and Update access to the view, the users will be be able to insert/update data from the view. They will not be able to insert/update directly to the table. However, if there are DENY insert/update permnissions on the underlying table, then the insert/update to the view will fail.
Here's a comprehensive link to permissioning.
SQL Server permissions
Related
Is there a way to lock down (preferably at the server level but DB level is also fine) tables and stored procedures? I don't want specific users creating new procedures or tables, but want them to be able to write to tables (via some Excel macros we have in place) and execute existing procedures. I would not want this to be a blanket policy, I'd prefer to specify which users this applies to.
Do you have individual ms SQL server logins for every user? Then you can set the access rights of these to Datareader and datawriter only in the security section or on database level.
If everyone uses the same login, you will have to create trigger on the data definition level. E.g. a trigger on CREATE TABLE that aborts any action.
Edit: I suggest you create a new login specifically for those excel macros.
I am creating a user that should only have access to the database tables metadata,via INFORMATION_SCHEMA, and not the table data. So no perms to query the tables directly. The role the user will be a member of will have USAGE privileges on INFORMATION_SCHEMA schema. I tested the user with that role and it is only able to see tables within public and no where else.
I did see in Snowflake documentation:
"The output of a view or table function depend on the privileges granted to the user’s current role. When querying an INFORMATION_SCHEMA view or table function, only objects for which the current role has been granted access privileges are returned."
So, I tried to grant to the role MONITOR and USAGE on other schemas; but, that did not work either. Only when I granted a role with read access to all the tables in the schema was it able to see and query from INFORMATION_SCHEMA.TABLES the tables in that schema. This, however, is not what I want as now that user would be able to query data from the tables. I just want to set that user to be able to query and gather the metadata of tables and not allow data access. Is there a way in Snowflake to setup and perform this type of setup?
I believe the only way to do this would be to provide access to the SNOWFLAKE.ACCOUNT_USAGE share on Snowflake, which also has TABLES and would allow this user to query the metadata of all tables and columns in that Snowflake account. There is a lot more information available in that share, but at least the user would not have access to any real data, if that is what you are after.
I am new to Snowflake. Is it possible to query Information schema views for eg, SCHEMATA, TABLES, COLUMNS for all tables in a snowflake Db without having select access to the underlying tables. The requirement is to create a user/account that only has access to query metadata of the snowflake Db and should not have a select access to the table data. Please advise.
From the Snowflake documentation:
"The output of a view or table function depends on the privileges
granted to the user’s current role. When querying an
INFORMATION_SCHEMA view or table function, only objects for which the
current role has been granted access privileges are returned."
In other words, you won't see the metadata for objects you do not have access to when you query the INFORMATION_SCHEMA views.
To workaround, you can use a role like ACCOUNTADMIN that has permissions to all tables and populate a new table with results from the desired INFORMATION_SCHEMA views. Then give your new role access to that table. You may be able to even setup a task in Snowflake to regularly update the table.
References:
https://docs.snowflake.net/manuals/sql-reference/info-schema.html#general-usage-notes
https://docs.snowflake.net/manuals/user-guide/tasks.html#executing-sql-statements-on-a-schedule-using-tasks
I believe you won't see the object in information schema views. So you required privileges to access the object.
The views in INFORMATION_SCHEMA display metadata about objects defined in the database, as well as metadata for non-database, account-level objects that are common across all databases.
There are 17 views available under INFORMATION_SCHEMA that holds information of Database level objects.
There are 8 views that holds information of Account level objects.
INFORMATION_SCHEMA is a read-only schema available automatically under each database. It stores metadata of all Snowflake objects built under the database.
Running Queries on INFORMATION_SCHEMA requires warehouse to be up and running which incurs Snowflake credits.
The output of a view or table function depend on the privileges granted to the user’s current role. When querying an INFORMATION_SCHEMA view or table function, only objects for which the current role has been granted access privileges are returned.
To use a database's information schema all you need is usage privilege on that database. The role in turn will only see content from the information schema that he/she has access to.
I am new to SQL Server database and I am struggling to figure out the access issue for one of the user on a particular view. I don't want to expose any of my base tables.
The scenario is: I have 3 databases, DB one, two and three
Database one has 2 base tables
Database two has one view on top of those tables (tables in database one)
Database three has one view which is on top of the view of database two
Database three is our data warehouse. So, I would like to know if I give select permission on only database three's view, will that suffice?
The catch is I don't want to expose any of my base tables in database one
If I grant select permission to user1 on datawarehouse view (view in database three) and deny all the permissions to the base tables (in database 1), then is it possible?
Thanks
Ownership chaining allows access to data via the view without permissions on the underlying tables as long as all objects are owned by the same security principal. There is no need for an explicit GRANT or DENY on the indirectly used objects with an unbroken ownership chain since permissions are checked only on the directly access view. The object owner is typically inherited from the schema owner.
To allow ownership chaining to extend across multiple database:
The DB_CHAINING database option must be ON for the databases involved.
The user must be able to use the databases (have a user account in each database with CONNECT permissions), although only permissions on directly accessed objects are needed.
In the case of dbo-owned objects, the databases must be owned by the same login (AUTHORIZATION) since the dbo schema owner is the database owner. For other schemas, the schema owner must map to the same login.
DB_CHAINING should be enabled only when you fully trust highly-privileged users (those with permissions to create database objects).
I want to push data to Excel from a restricted table.
I've created a view and pull the data from the table, now an Excel account has been granted to access the view but still can't get the data.
What's the best option here,
owner access option, if possible at all in SQL Server (making the view run as dbo, even when called from Excel user) - may be counter-security
Stored procedure?
regards,
The stored procedure drove me all the way home.