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
Related
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.
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.
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.
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.