Does anyone know if Snowflake, or anyone else, has published a comprehensive list of activities that can be performed in Snowflake and the list of privileges required to allow a user to do that?
For example, to describe a database (Describe Database statement), I think you need the Ownership privilege on the database OR the Monitor privilege on the database.
It would be VERY useful to have a list of common activities and the privileges needed to perform them.
Snowflake documentation contains a comprehensive list on that topic:
Access Control Privileges
"For example, to describe a database (Describe Database statement), I think you need the Ownership privilege on the database OR the Monitor privilege on the database.
Database Privileges
Privilege
Usage
MONITOR
Enables performing the DESCRIBE command on the database.
ALL [ PRIVILEGES ]
Grants all privileges, except OWNERSHIP, on a database
OWNERSHIP
Transfers ownership of a database, which grants full control over the database.
Related
An application vendor representative asked me to grant dbowner access to tempdb for their application login; to be able to create objects in tempdb without "#" or "##" prefixes.
I tried to convince him to forget asking for direct tempdb access by arguing that granting direct access may interfere with SQL Server engine internal operations and prevent tempdb cleanup processes to do their jobs correctly. And also there is another drawback on SQL Service restarts which causes any permission setting on tempdb to revert to defaults.
Is there anything that I might miss in this regard?
I just added an audit table to a project. The db (postgresql) superuser still has all its privileges on that table. This means the data in the audit table could be edited, ergo corrupted, at any point by the superuser.
The question is, is this a theoretically/legally acceptable audit log?
Yes, absolutely. You only have to define that there is reliable auditing only for non-superusers.
There is no way in PostgreSQL to reliably protect information from the superuser. The superuser has full access to all information that PostgreSQL can read or write.
To protect your auditing system from tampering by a superuser, the component that collects and persists the auditing information would have to belong and run by an operating system user different from postgres.
Consider that a tablespace is defined in one schema of oracle database. If i want too access the tablespace from another schema, Will it be working out or is there any grant permission to be declared. Please let know the method to access it.
As #alexpoole said, tablespaces are database constructs in Oracle, not schema constructs. To grant a schema the ability to place objects in a tablespace, you must grant quota.
In the code below, we are granting user (schema) CQADM quotas on three tablespaces starting with "GP", one quota is 50 megabytes, one 1 gigabyte, and the last unlimited.
ALTER USER CQADM QUOTA 50M ON GP_FRACTURED_TS;
ALTER USER CQADM QUOTA 1G ON GP_TS;
ALTER USER CQADM QUOTA UNLIMITED ON GP_TS2;
Is there any possible way to prevent dml operations for a specific user schema is busy traffic hours without impacting other user schema's dml operations
Depending on who has grants to insert/update/delete/execute on that user's objects it could be as easy as
ALTER USER myuser ACCOUNT LOCK;
ALTER USER myuser PASSWORD EXPIRE;
and then unlock and unexpire once you're done.
If other users have access to that schema then I don't think there is a simple way.
I have database that is a datawarehouse environment that loads data with an ETL process.
During the ETL process I wish to make the database unavailable for querying for certain roles.
What would be a possible solution?
I think the easiest answer would be to REVOKE PERMISSIONS for the rolls in the ETL process and reverse it at the end (or on fail).
One option would be to create a stored procedure which modifies the permissions of the roles, then drops users connections, then following the data load you reset permissions.
An alternative to this is to run your ETL process when no one is using the system...