I need something similar to mysql's GRANT SELECT ON db.* TO user in postgresql 8.4. The solutions I find online use a for loop to select tables on at a time and grant privileges on them. But that would mean I would have to rerun the command every time a new table is added to the database.
Is there a more straightforward solution to this?
Assuming you don't have any specific schemas defined, all your tables will be in the 'public' schema, so you can say:
GRANT <permissions> ON ALL TABLES IN SCHEMA public TO <roles>;
This only works on 9.0 or above though, so you're out of luck in 8.4.
See also: http://www.postgresql.org/docs/8.4/static/ddl-schemas.html
Note that often granting a certain user's rights to another user makes as much or more sense and is easier to keep track of.
create user dbuser9;
create database test9 with owner dbuser9;
\c test9 dbuser9
create a bunch of stuff...
\c postgres postgres
grant dbuser9 to stan;
Default privileges came with version 9.0, it's not available in older versions.
You can create a stored procedure that loops through all tables and sets the privileges.
Related
Apologies for the new question, but I am having trouble understanding the best practices for understanding the recommended role set up for my account. I am auditing what I have created to backwards engineer and correct it on a new warehouse.
So here is the situation:
I granted all permissions on all warehouses modify AND usage to the sysadmin.
When running worksheets and ./snowsql in parallel, I used the ACCOUNTADMIN for all of the sessions in snowsql.
When I use the Sysadmin to modify the tables that copied the data staged in the warehouse sometimes I have permissions and other times I don't.
I have been sifting through account history with the ACCOUNTADMIN role to view all the grants with the recommended query from the documentation below:
select *
from table(information_schema.query_history())
order by start_time;
I filtered then by the database and query_id to include grant
select *
from table(information_schema.query_history())
where database_name = 'temp_db'
and query_id like '%grant%'
order by start_time;
I did this to see if there were any differences in the grants I did between databases in the warehouse. I only set up two warehouses so it was easy to see.
Going forward, Accountadmin is used to create roles, warehouses, and databases.
To prevent the need to do an audit when switching between roles, I want to set future grants on Sysadmin to specific databases in a warehouse for modification and usage, how do I do that?
Permissions to warehouses, database, and all other objects are separate things. Granting permissions to a warehouse let's that role use or modify a warehouse, but that has nothing at all to do with creating, updating, etc. other objects like databases, schemas, tables, and views. Also, only the role that OWNS a table can drop or alter a table. So, you might want to check on the ownership of the tables between SYSADMIN and ACCOUNTADMIN. As a best practice, ACCOUNTADMIN shouldn't own anything.
It would take quite a bit more information to give you a full rundown of RBAC in Snowflake. If you are struggling with it, you might want to contact Professional Services at Snowflake and get them to come in and do an overview (QuickStart or Security package) to get you straightened out.
I want to grant read permissions for a user for a view which joins 2 tables from another database.
I don't want to:
give him permission on the database where the tables are or add him as an user there.
Make him the owner of the view/schema due to the security exploits.
I don't want to create first a table, or variations of a hack table with a truncate and a stored procedure which inserts the data on a trigger.
Can this be done somehow? Maybe there's something I missed and you guys might know.
I have read these posts but they didn't solve my problem:
Grant SELECT permission on a view, but not on underlying objects
Grant Select on a view not base table when base table is in a different database
https://msdn.microsoft.com/en-us/library/ms188676.aspx
https://dba.stackexchange.com/questions/89632/sql-server-grant-select-access-to-a-user-in-a-view-and-not-in-its-tables
Thank you
Edit:
The easiest solution I came up with, after some research, is activating the cross database ownership chainingoption on the database where I'm placing the views and granting the read permission to the users. This might be in contrast with my 2nd point of things I'm trying to avoid. Is this a good idea?
Give them a login to another database on the same server, and include only your single view, with the view pointing to your secure database. Don't give that login any access to anything but the database with the view in it, and only read access to that single view. Obviously, you'll have to fully qualify your table name (e.g., from SourceDB.dbo.SomeSecretTable).
What I ended up doing:
Create an active directory group.
Add users to the AD group.
Create a login for the AD group mapped for the source DB and target DB.
Add the user on the target DB and give him permissions only for the requested views.
(Optional) Added the group on all the databases to deny select.
Couldn't find a solution for my original question without the AD group.
Is there a way to list table and column names where I am not granted access? I am a developer trying to access and see if a column name is available but dba's are restricting any sort of read 'select' access. This is for SQL Server 2008. Thanks.
It would be best to open up communications with your DBA for this issue. Technically speaking there is a way to do this however the DBA is likely the only one that can provide this information. Which asking what you have permissions to is not an unreasonable request in my eyes (as a DBA).
You might also suggest that in place of you having to ask them these types of questions over and over if they can grant you VIEW DEFINITION on the particular database. This grants you metadata access to objects in the database without granting access to the objects themselves.
No, there isn't. The SQL Server will not expose any metadata on objects you dont have a privilege to use. So, if you don't have a SELECT permission on a table, you won't see it's metadata. Same with stored procedures etc.
Try this:
select * from INFORMATION_SCHEMA.TABLES
select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME='<name>'
Not sure if the DBA's restricted access to these views or not
While working with some random sql queries on our databases, we may not want to insert or delete items to some of the database tables by just typing their names by mistake. So how to make them locked to the "editing", to be able to work safe.
Thanks.
Why not just define a role in your database and give that role rights to whatever tables your users need, but this role would not have update/delete rights to the tables you are concerned with?
As the others have mentioned, this should be set up in the Roles.
Here is a useful link on Understanding Roles in SQL Server 2000
Work with a limited-rights account, and deny it rights to modify the 'protected' tables.
Roles are the best practice way to go. However if you can't/won't use roles, you could use triggers, see this answer: SQL Server Query Editors - any that warn of number of rows to be changed?
Move these special tables to its own database. Give the user account only select privileges for this database.
At least on my local instance, when I create tables, they are all prefixed with "dbo.". Why is that?
dbo is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace.
If you are using Sql Server Management Studio, you can create your own schema by browsing to Databases - Your Database - Security - Schemas.
To create one using a script is as easy as (for example):
CREATE SCHEMA [EnterSchemaNameHere] AUTHORIZATION [dbo]
You can use them to logically group your tables, for example by creating a schema for "Financial" information and another for "Personal" data. Your tables would then display as:
Financial.BankAccounts
Financial.Transactions
Personal.Address
Rather than using the default schema of dbo.
It's new to SQL 2005 and offers a simplified way to group objects, especially for the purpose of securing the objects in that "group".
The following link offers a more in depth explanation as to what it is, why we would use it:
Understanding the Difference between Owners and Schemas in SQL Server
Microsoft introduced schema in version 2005. For those who didn’t know about schema, and those who didn’t care, objects were put into a default schema dbo.
dbo stands for DataBase Owner, but that’s not really important.
Think of a schema as you would a folder for files:
You don’t need to refer to the schema if the object is in the same or default schema
You can reference an object in a different schema by using the schema as a prefix, the way you can reference a file in a different folder.
You can’t have two objects with the same name in a single schema, but you can in different schema
Using schema can help you to organise a larger number of objects
Schema can also be assigned to particular users and roles, so you can control access to who can do what.
You can generally access any object from any schema. However, it is possible to control which users have which access to particular schema, so you can use schema in your security model.
Because dbo is the default, you normally don’t need to specify it within a single database:
SELECT * FROM customers;
SELECT * FROM dbo.customers;
mean the same thing.
I am inclined to disagree with the notion of always using the dbo. prefix, since the more you clutter your code with unnecessary detail, the harder it is to read and manage.
For the most part, you can ignore the schema. However, the schema will make itself apparent in the following situations:
If you view the tables in either the object navigator or in an external application, such as Microsoft Excel or Access, you will see the dbo. prefix. You can still ignore it.
If you reference a table in another database, you will need its full name in the form database.schema.table:
SELECT * FROM bookshop.dbo.customers;
For historical reasons, if you write a user defined scalar function, you will need to call it with the schema prefix:
CREATE FUNCTION tax(#amount DECIMAL(6,2) RETURNS DECIMAL(6,2) AS
BEGIN
RETURN #amount * 0.1;
END;
GO
SELECT total, dbo.tax(total) FROM pricelist;
This does not apply to other objects, such as table functions, procedures and views.
You can use schema to overcome naming conflicts. For example, if every user has a personal schema, they can create additional objects without having to fight with other users over the name.
Something from Microsoft (Documentation)
The dbo user is a special user principal in each database. All SQL Server administrators, members of the sysadmin fixed server role, sa login, and owners of the database, enter databases as the dbo user. The dbo user has all permissions in the database and cannot be limited or dropped. dbo stands for database owner, but the dbouser account is not the same as the db_owner fixed database role, and the db_owner fixed database role is not the same as the user account that is recorded as the owner of the database.
The dbo user owns the dbo schema. The dbo schema is the default schema for all users, unless some other schema is specified. The dbo schema cannot be dropped.
The dbo user owns the dbo schema. The dbo schema is the default schema for all users, unless some other schema is specified. The dbo schema cannot be dropped.
DBO is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace. As a best practice, I always add the "DBO." prefix even though it is not necessary. Most of the time in SQL it's good to be explicit.