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.
Related
I am new to SQL server and now I have a database with thousands of tables stored. I want to replicate this database and pass this replica to other vendors, but for security concern, I would like to mask all the fields in the tables. The vendors don't really care about what has stored in the table but they do care about the structures or distributions about the tables.
The idea is to copy the current database and do masking then. But I don't know if SQL server has provided this technique to simplify the process. Appreciate it for any comments or suggestions!
Just deny view definition permission to the user who will access the database using the below query :-
USE master
GO
DENY VIEW ANY DEFINITION TO User1
Once you deny this permission to User1, all objects such as table,SP,view etc will be hidden in the database and at the sametime user1 will be able to do whatever he wants if he knows the object.
This will mask the all objects from the user.
I know I can't make my user in RDS a sysadmin...but can I at least change the database owner from rdsa to my own user? If I use SSMS and go to change the Owner in the database properties, I get the message:
The proposed new database owner is already a user or aliased in the database
Why do I want to do this instead of just adding my user to the db_owner role?
I have indexed views I want to create, and when trying to do so, I get the error
Index cannot be created on view '...' because the underlying object '...' has a different owner.
I know that I can manually use ALTER AUTHORIZATION on the underlying objects to allow this, as described here: https://dba.stackexchange.com/questions/9436/sql-server-2008-cannot-create-index-on-indexed-view. But I really don't want to do that for every single object referenced by every one of my indexed views.
I'm certainly open to suggestions on alternative approaches.
Thanks.
Index cannot be created on view '...' because the underlying object
'...' has a different owner.
This is the real problem you're trying to solve, right? Changing the database owner (which would be done by running ALTER AUTHORIZATION ON DATABASE::<dbname> TO <loginname>) is just a red herring.
To solve this problem is unlikely you need change th owner of the underlying object, is far more likely you want to change the owner of the view, and probably correct solution is to create the view in the same schema as the underlying table:
create view schema.indexedView
with schemabinding
as
select ...
from schema.table
where ...
Note that I say 'likely' and 'probably', this is not excuse I'm uncertain of the solution. Is because only you can tell us who the owner should be, based on the specific business rules, audit settings and access permissions of your site. Also, the fact that everything is database contained (the table, the indexed view, the schema containing the table and the owner of the schema) it means that the fact that this is an RDS instance is completely irelevant.
In Oracle,
- I want to ensure that owner of trigger must match table owner.
- Also the views should be restricted. The user must not be able to query system views and tables.
Generally only the owner of a table will have privileges to create triggers on it. DBAs may have the privilege CREATE ANY TRIGGER, but protecting a database from a DBA is whole different order of question.
There are a number of system views (eg USER_TABLES, ALL_USERS) which you can't revoke access on, but they will only reveal what the user has been granted access to. Again the DBA will have access to views prefixed DBA_ and 'views' prefixed V$ (which are a bit odd in that they show operational information about the database and not data that is stored on disk anywhere) and tables owned by SYS.
What exactly is it that you want to accomplish?
Normally, we create roles that give access to only the application tables and views.
The owner of the application grants privileges to those roles and
the roles are granted to your users.
As long as the owner of the tables only has the regular 'create xxx' privileges, there is not much to worry for. Normally we need access to some system tables and views.
What data do you want to hide? Most of the views don't reveal more than already is known by the application.
Don't give 'xxxx ANY' privileges to anyone. Most of the time when those privs are requested it is because of laziness. They are rarely needed.
Ronald.
whats the best way to grant access to a few users to a couple tables in a SQL Server 2005 database?
I know the literature pushes the use of views but what is the gain over granting read only access to the actual table?
at least with the table there will be less overhead in that the index and other restraints are already in place and managed at the table (a single point of maintenance). If I make views then won't i need to maintain them and create indexes on them... as well as this will be additional overhead for SQL itself?
CREATE ROLE role_name
GRANT SELECT ON table_name TO role_name
Don't forget to add users to that role. Adding individual permissions is generally a bad practice.
Using views and giving permissions to the view is useful if you want to hide particular columns / name columns in different ways / otherwise filter the data.
I'm working with a database (let's call it DB_data) that contains all of the tables for a series of applications. In an attempt to minimize downtime during upgrades, a facade database (let's call it DB_facade) has been created which has a view for each of the tables in DB_data. It also contains all of the functions and stored procedures, which work against these views.
In trying to lock down security in DB_data we've done a DENY on all of the tables for all of the users in DB_data. All of these users have also been created in DB_facade with permissions to the views.
The problem here, is that because of cross-database ownership chaining the DENYs in DB_data are overriding the GRANTs in DB_facade.
I'd like to avoid turning on ownership chaining for both of these databases because of the potential security issues (although in my original tests, that did seem to correct the access problem). Also, we're trying to minimize impact to the applications, so requiring all access to be through stored procedures and using certificates (for example) wouldn't work.
Does anyone have any other suggestions on how to handle this?
Thanks!
Do you have this problem if you exclude the DENY on the tables in DB_data? If you don't explicitly GRANT permissions on these tables, you may be able to get the security you need and get the access rights through the views.
from what i've seen and done, sql server doesn't let you have any permissions unless explicitly told so. You should be able to grant select (or use the role datareader) in DB_Data to the users, and as long as it's the same account and it's mapped to both databases (you'll have to grant select and exec on db_facade) that should work just fine.
You can create a view in the DB_data database for each view in the DB_facade database. The new views would have rights to select from the tables. GRANT SELECT on the views in DB_data. Change the views on DB_facade to SELECT from the views on DB_data. And, the tables would have DENY set.
I recognize one disadvantage to this; the users can still interact with the DB_data database. They wouldn't be able to access the tables, but they could access the new views.