In MS-SQL Server 2008 R2, is there a way to set a table permission to "deny all" (select, insert, update, delete), to all roles and user id (including the future ones), except to sa?
In other words, can a table be made invisible except to sa?
No
db_owner will see it
schema owner can see it
references in a stored procedure won't check permissions
...
If you want an invisible table, put into it's own database and set no permissions at all. No need to DENY, just do not GRANT or CREATE USER
Related
we have a postgres database we want to run a number of checks against. Part of the tool involves looping over database all the database tables and views, checking grants and other things - so it would be entirely pointless if we had to grant access to this user to individual tables.
We want to be able to create a user that has full read privileges to anything, regardless of what permissions are set in the database - like a db owner - but has no write access at all.
Is this possible in any way?
The only way to do this is granting the SELECT privilege on every individual object that needs to be examined. You can make the work easier with
GRANT SELECT ON ALL TABLES/SEQUENCES/... IN SCHEMA ... TO ...;
You can also use ALTER DEFAULT PRIVILEGES to set the permissions on future objects.
I recommend that you create a readonly role and do all that once. Then you can create a read-only user by making the user a member of that role.
With postgresql 14 you can just do:
GRANT pg_read_all_data TO my_role;
https://www.postgresql.org/docs/14/predefined-roles.html
Is it possible to set role with access to one database, with all privileges except to drop tables?
Not really. If a user can issue CREATE TABLE, it can issue a DROP for that table as well. From the docs:
The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked.
And as noted by the CREATE TABLE docs:
The table will be owned by the user issuing the command.
There is no mechanism to allow a user to create tables that they do not own and therefore cannot drop.
I have SQL2008R02 database user added to the data reader role. This user can SELECT all tables. But I want to him to restrict him from one table. How do I do this? I do not want to run GRANT SELECT individually on all tables except one.
You can use a DENY permission on the one table, for example:
DENY SELECT ON myTable TO myUser
DENY "permissions" are available in SQL 2008 onwards.
https://msdn.microsoft.com/en-GB/library/ms188338.aspx
I have a multi-schema, multi-user Postgres DB. There is one table that I would like ALL users, both current and future, to be able to SELECT from.
I can GRANT SELECT to all current users... but how can I create a table that allows any future user to select? Is there a way to set table permissions, rather than granting user privileges?
A filesystem analogy would be using chmod to make a file to be readable by the public.
grant select on the_table to public;
From the manual:
The key word PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. PUBLIC can be thought of as an implicitly defined group that always includes all roles
When I try to alter a table from a different owner in Firebird I got this error:
unsuccessful metadata update
MODIFY RDB$RELATION_FIELDS failed
no permission for control access to TABLE TAGS
I had already granted ALL privileges to this user, also REFERENCES privileges, but I still getting this error.
Does anybody knows how to solve this?
I use Firebird 1.5
Thanks
The Firebird 2.5 Language Reference section on ALTER TABLE states:
Only the table owner and administrators have the authority to use
ALTER TABLE.
In other words if you are not the owner of the table, you need to either login as SYSDBA, or you need to be logged in as root or Adminstrator on the machine with the database. There is - as far as I am aware - no other way to alter a table as a different user.
In Firebird 2.5 there is also the RDB$ADMIN role which allows a user which is granted this role to act with the same rights as SYSDBA.
The rights you can GRANT (except for REFERENCES) are only for DML, not for DDL operations.
Firebird 3 introduced metadata privileges, which allows you to grant these permissions to a specific user or role for specific object types.
For example:
GRANT ALTER ANY TABLE TO Joe;
Will allow the user Joe to alter any tables in the current database.