In a Netezza database, what exactly does the 'LIST' privilege do? I understand what a 'SELECT' privilege does, but what does 'LIST' allow a user to do?
LIST is an object privilege, and is required to see the object (usually the object's name in a list).
SELECT object privilege does implicitly grant LIST, so you can always see a table that you can SELECT from, but LIST doesn't imply SELECT.
You can find information on Netezza object privileges here.
Related
I need to check whether row-level-security applies to the current_user in a Postgres query. As far as I can tell, I need to check whether the current user is the owner of that table, or has the BYPASSRLS attribute, or is member of a role that has this. That group membership check seems cumbersome though, especially considering the NOINHERIT attribute of some roles… How to achieve this?
I need to check whether row-level-security applies to the current_user
Indeed there is a much simpler way to check that - in particular for a specific table, which the user (or one of the inherited roles) might be owner of. The solution is to use the row_security_active function:
row_security_active checks whether row level security is active for the specified table in the context of the current_user and environment. The table can be specified by name or by OID.
So just use
SELECT row_security_active('schema.table');
I am maintaining a database 'db' in which there are around 100 tables.I have one super user 'A' and 'A' is the owner of all tables. How can I give Alter permission to new user 'B' specific to single table without inheriting all permissions from 'A'.
I tried by providing Grant A to B;. This Grant option given all permissions from 'A' to 'B'. I want above scenario to restrict to one particular table.
Is this possible?
The documentation recently acquired this explanation:
The right to modify or destroy an object is inherent in being the object's owner, and cannot be granted or revoked in itself. (However, like all privileges, that right can be inherited by members of the owning role; see Section 21.3.)
So the only people who can run ALTER TABLE are:
Superusers
the table owner
members of the table owner role
So GRANT a TO b is the only way to give somebody the privilege.
You might be able to use a SECURITY DEFINER function that belongs to a, but be careful with that.
I am working around a workaround to a "feature" in IBM DB2.
This fancy database has a "feature" in it which if I try to use a CREATE TABLE statement and it doesn't find the schema, it will create this schema for me, even if I don't want it to. This bug has caused me a lot of hours in debugging, because my code right now exists with the expectation that it won't create the schema if it doesn't exist
My question is -- how do I change the permissions of a particular schema (or even during the create schema phase) which a particular user does not have access to view?
I checked out this doc..
It seems with GRANT, there are the following three permissions:
ALTERIN
Grants the privilege to alter or comment on all objects in the
schema. The owner of an explicitly created schema automatically
receives ALTERIN privilege.
CREATEIN
Grants the privilege to create
objects in the schema. Other authorities or privileges required to
create the object (such as CREATETAB) are still required. The owner of
an explicitly created schema automatically receives CREATEIN
privilege. An implicitly created schema has CREATEIN privilege
automatically granted to PUBLIC.
DROPIN
Grants the privilege to drop
all objects in the schema. The owner of an explicitly created schema
automatically receives DROPIN privilege
With only ALTERIN, CREATEIN, and DROPIN, I don't see anything relevant to view access permissions :/
EDIT:
I checked out our Dash DB database for this particular table which has these special permissions for particular users using the following SQL:
SELECT * FROM SYSIBMADM.PRIVILEGES WHERE OBJECTSCHEMA = 'FAKE_SCRATCH';
This is the result:
EDIT 2:
I tried the following to emulate Dash DB's permissions for that user for that schema:
GRANT ALTERIN, CREATEIN, DROPIN ON SCHEMA FAKE_SCRATCH TO USER TEST_USER;
Still doesn't work :/
The following SQL query executed in DB2 fixed the problem:
REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC
I have access to some schema in different database and as part of some migration work, I am comparing 2 schema.
I am using Syscat to compare the 2 schema. However in one of the schema, I get an error saying
"user does not have select privilege on "
I would like to know , how can I see what and all access permissions have been set up in a particular schema (basically all users who have access and the type of access for a gievn schema). The database is db2.
Please note that I am not using any tool like schema crawler etc. Instead I am writing a JDBC application which uses the Syscat to query the details like select * from syscat.tables where tabSchema = <schemaName>
Using a tool etc is a long process in terms to getting approval , justification etc (and I personally think that JDBC program should be good to start with the analysis).
In DB2 privileges granted on a schema do not give you any privileges on objects belonging to that schema (unless you created those objects yourself). You have to be granted explicit object privileges or certain database level privileges, such as DATAACCESS.
The actual DB2 error message should contain the name of the object that generates the error. Try printing the String representation of the SQLException object.
A schema is a logical group of objects. These objects can be views, tables, indexes, sequences, functions, sotred procedures, etc. Each of these objects has a different set of privileges: table has select, insert, delete and others; stored procedure has the execution and others; etc. It means that every single object has different types of privileges, and you cannot get "all privilegesfor a given schema", you have to give the type of object.
For example, in order to get the privileges on tables for a given schema, you can execute
db2 "
select substr(GRANTEE,1,16),GRANTEETYPE,substr(tabschema || '.' || tabname,1,64),
CONTROLAUTH, ALTERAUTH, DELETEAUTH, INDEXAUTH, INSERTAUTH, REFAUTH, SELECTAUTH, UPDATEAUTH
from syscat.TABAUTH
where tabschema like 'MYSCHEMA%'"
Each kind of object that a table in syscat schema that contains the privileges for that kind of object. You just have to query the table.
In a similar way, you can create the appropiated sentences in order to grant or revoke privileges on an object
select 'grant select on ' || trim(tabschema) || '.' || trim(tabname) ' to user johndoe'
from syscat.tables
where tabschema like 'MYSCHE%'
Finally, there are not only privileges (grants) on db2, there are also database level authorities, and some of them have privileges on all objects.
Using psql, \dg and \du tells me the roles that each user (role) belongs to. I want to determine this programmatically for a single user but cannot find which system tables are used to generate the results returned for \dg.
Will I need special privileges to execute this query?
As a related question, I want to determine what tables a role can update.
I've read the documentation on CREATE ROLE and GRANT and surrounding documentation which tell me how to set up roles and privileges, but not how to test for role membership or table access privileges.
There are built-in system information functions for both. See pg_has_role, etc.
You can also query the information_schema to get role membership data, in particular information_schema.applicable_roles, information_schema.enabled_roles and information_schema.administrable_role_authorizations.
Finally, for any psql \d command you can find out what exactly psql is doing to get the information by running psql with the -E option to print the sql it runs. I don't recommend using psql's sql when there's a builtin function or an information_schema view for the same information though. psql's approach may be faster but it's also more PostgreSQL-version-specific and may not work with PostgreSQL versions other than the one you're running. In the case of \du and \dg psql will be querying pg_catalog.pg_roles as part of a join against other tables. It's much simpler and more portable to use the information_schema views instead.
This really should be the documentation entries on role membership; I'll post a patch that adds appropriate cross-references.