This afternoon I was reviewing the security for a user in my SQL Server, in SQL Server Management Studio. I opened the Database User's Properties dialog, and went to the Securables section.
As I was cycling through the tables and stored procedures that this particular user had access to, I noticed that one of the data tables had the the Update option checked in an intermediate state. What does that mean? You can either update a row, or you can't. There is no in-between. I've included an image for reference. I would just fully check this option and save it but I'd rather not screw with the DB if this serves a worthwhile purpose.
I believe that means that that permission has been inherited and wasn't explicitly set for that user.
The GRANT statement can assign
permissions to a group or role that
can be inherited by database users.
http://msdn.microsoft.com/en-us/library/bb669084.aspx
I'm trying to find something that specifically spells out that's what the checkbox looks like in the above situation.
Related
I am using SQL Server 2017. I am in the role of sa for the server in question. I have two databases that are used in an ETL process. The ETL is coded in one database, and the raw imported tables are located in the staging database. All ETL is handled in SQL stored procedures that follow a pattern. The first step in each ETL SP is a call to a diagnostics table in the staging database.
My current ETL job is a wrapper around two of these ETL sps; the wrapper itself contains only code that accesses the main db.
The first SP can be called and successfully selects the data from the staging db, however, the second SP that has identical code up to the point of failure with the first, fails on accessing the diagnostics table and tells me
The server principal "sa" is not able to access the database "staging" under the current security context.
The problem stays if I comment out the first SP call, so something must be different in the definition of the two SPs, but I cannot spot it.
There are plenty of SPs that use the diagnostics staging table, so it is not a general problem (as stated in answers to similar questions that suggest changing security options in the staging database), but must be related to the new SP somehow.
Any suggestions?
There are three things to check/do.
First of all, the login associated with the user in database DB1 must also be associated with a user in DB2. This provides the login with a security context in database DB2. The sa login will map to dbo in both databases, so this should already be fine.
Second, the security context of the code being executed in DB1 must be "trustworthy". In other words, when the user context goes from DB1 back up to the server level and then down into DB2 via the cross-database call, the new user context has to trust the original login. There are two ways to do this, the quick and dirty and opens-up-possible-security-holes way, and the more complicated but safer way:
Quick and not entirely safe: alter database DB1 set trustworthy on.
Safe: Use signed modules
Third, in the general case you should check that the owner of DB1 and the owner of DB2 are the same (otherwise you can't cross database ownership chain): select owner_sid from sys.databases where name in ('DB1', 'DB2') But as with the first point, as a sysadmin you can take ownership of anything.
As too often happens, I failed to recognize a subtle difference between the two stored procedures: They both call a logging stored procedure, but this logging procedure has two variants, one with prefix sp_, and another one with the prefix usp. (Someone reacted to the Microsoft warning not to use sp_ as prefix.) The old one had an 'execute as owner' inside, which caused the error.
Replacing the function call with the new version fixed the error.
Sometimes the error is on the other side of the screen.
I have a SQL Server table that has four columns in it, one of which is a datetime column with a default value of getdate(). I have two copies of this table, one in a development database server over which I have full control, and another in a production database server in which I have few permissions.
Here is how the development table looks:
I've selected the dtInsert column. Notice that this column has a default value of getdate(). The production version I have of this table is exactly the same. When I add a row to this table, the dtInsert cell defaults to getdate() like I'd expect. When a database administrator generates a script of the production table, it includes the default value constraint. However, when I view the table design in SQL Server Management Studio 2012, it shows the column as not having a default value. See here:
When I generate a database diagram, it also shows the dtInsert column as having no default value. Again, I know from testing that the dtinsert column in my production database server indeed defaults to getdate().
Is this a bug in SQL Server Management Studio version 2012? Is there some permission I don't have which brings about this behavior? Is it something else? Why does the column appear to have no default value even though it does?
Is this a bug in SQL Server Management Studio version 2012?
No.
Is there some permission I don't have which brings about this behavior?
Yes.
In a comment on the question I suggested running the following:
SELECT *
FROM sys.default_constraints
WHERE [parent_object_id] = OBJECT_ID(N'_table_name_');
The result was a row return in Production in which the [definition] column was NULL. This means that the DEFAULT CONSTRAINT is there but you either:
lack explicit and implied permissions to see the definition
have been explicitly denied the permission to see it.
You can read up on this on the MSDN page for Metadata Visibility Configuration.
Now, there are various permissions (VIEW DEFINITION, VIEW ANY DEFINITION, etc.) that affect this setting. These can be applied at various levels:
the object itself
the schema
the database
etc
Permissions get further complicated when taking into account membership in multiple Windows Groups (if those are being used).
The permission can even be granted at multiple levels. Permissions are also additive: a GRANT in 1 out of 3 Windows Groups that your Login is a member of is enough to work. However, a DENY in any of those levels takes precedence and in that case, no definition for you.
As I mentioned in a comment on the question, this is really a matter for the Production DBA(s) who configured permissions such that you can't see the definition. Without know exactly why you can't see the definition (lacking of a GRANT or presence of a DENY?) it is useless issuing GRANT statements trying to get this permissions (especially since not being able to see the definition implies that you likewise would not be able to GRANT such permission to anyone). Please go talk to whoever is in charge of Production telling them that you can't see the definition of a default constraint, but you would like to be able to. If there is a specific reason why you currently cannot, you will be told. If it is an oversight, they should correct it in a controlled fashion that might need to be replicated to other environments, etc.
It appears the difference in viewing the object in SSMS between dev and prod is due to permission differences on your user account between dev and prod.
In order to view default values on a table object you need to have at least one of the following permissions on the object to see the default value:
ALTER on OBJECT Or CONTROL on OBJECT Or TAKE OWNERSHIP on OBJECT Or
VIEW DEFINITION on OBJECT
Found this https://dba.stackexchange.com/questions/78769/minimum-sql-server-rights-that-allow-viewing-column-default-values
which seems to be pretty much answer your question :)
We're running SQL Server 2012 / .Net Framework 4.5.1
We have an application that does the following:
Extract all table data from a source database using an instance of .Net's SqlBulkCopy.
Delete all data in a target database using regular SQL statements.
Deploy the data from the source database to the target database using an instance of .Net's SqlBulkCopy.
The third step is successful when the SQL connection uses my Active Directory account, but fails with the following error message when using a SQL Server account created for this purpose: Cannot find the object "[SchemaName].[TableName]" because it does not exist or you do not have permissions.
Interestingly, the process runs through about a dozen tables before hitting one that causes this error. Manual verification proves that a) The table exists on the target, b) The problem user can select from the table, and c) the problem user can manually insert into the table with the standard INSERT INTO [SchemaName].[TableName] ([Columns]) VALUES ([Values]) format. BCP also works for that user, but using SqlBulkCopy from a .Net application fails for the same user.
Our DBA (A pretty seasoned guy, so far as I can tell, actually) says that the database permissions on the target database are IDENTICAL between the two users, but reality would seem to suggest this is not the case.
Googling the problem shows that the user should have the db_owner or db_ddladmin roles. The user actually belongs to both.
Anyway, solving the local problem is of secondary concern, since I can get done what I need done with my AD account. What I'd really like to know is whether there is a baked-in way to compare the differences in permissions between two users. If not, can this be done with a T-SQL query of some kind?
Thanks, guys and gals!
Here's my permissions script that I use. It's generally the approach that everyone uses, unless they have a schema compare product via Visual Studio, Red Gate, etc. http://www.csvreader.com/posts/permissions_list.php
Are you specifying the schema on the destination table with SqlBulkCopy? Is it possible that you're running into a user owned schema instance?
It's also been my experience that SqlBulkCopy only requires select and insert on the destination table. BCP requires the escalated permissions that you described, which is another benefit of SqlBulkCopy.
I am new to Oracle SQL Developer (about 1 month of use), having always used Toad. I have 2 almost identical schema set up - one to test older code, one to develop a modified versions. I have 2 different connections set up - one to each schema, with separate user names for each one.
But when I delete a table or column from the schema in one connection, it is also deleted or changed in the other.
This happens if I right-click on the table or field in the Connection explorer panel, or if I open a SQL Script saved to disk. If I open a SQL script, I even see a pop-up that asks me what connection to use, but if I select one, it still makes changes to both. Even if I only have one of the two connections open, the script will still change design in both of the connections.
The only way I can be sure to make changes to just one of the two is to right-click on the connection name in the Explorer panel, and open a new SQL Worksheet. The worksheet is then named for the connection and just makes changes to it.
This is not the behavior I was expecting, and I'm facing many hours of work to get the definitions of the 2 schema back to where I need them to be. I am wondering if there is some key concept or distinction I am missing or if there is some way the database(s) are set up that is enabling this to happen.
In case you never found the answer for your question. This is my understanding:
The database may have several schemas. The schema is not a separate database, it is a grouping of objects in that database. If you change something while in one schema, you are really changing it in the database, not just the schema. I hope this helps.
Are you just trying to test things in one schema? It sounds like you may want to have a Database and a TEST Database. You could test whatever you wanted in the TEST database and never have it change the real database.
In SQL Server 2005, a snapshot of a database can be created that allows read-only access to a database, even when the database is in "recovery pending" mode. One use case for this capability is in creating a reporting database that references a copy of a production database, which is kept current through log-shipping.
In this scenario, how can I implement security on the "snapshot" database that is different from the "production" source database?
For example, in the production database, all access to data is through stored procedures, while in the snapshot database users are allowed to select from table in the database for reporting purposes. The problem the I see is that security for the snapshot database is inherited from the source database, and can not be changed because snapshots are strictly read-only.
Are you able to manage permissions on this database? Would adding a separate user who only has read access to a database be sufficient for this type of scenario? This could be a read-only user on the main database, but is only effectively used on the snapshot db.
i.e. Add a new user, readerMan5000 who is only given select access, to the database in question. Then require users to authenticate through that new credential.
Note to future commenters, you may want to read:
http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/
or
http://msdn.microsoft.com/en-us/library/ms187054(SQL.90).aspx
before you open your big mouth like me. :)
You can't change permissions after you take the snapshot, but here's one workaround: instead of having them access the tables directly, require them to use views instead. If the views are used only for reporting, then you can set tight security on them in the original database, and then have the users hit those views in the snapshot. You'll need to restrict access on the underlying tables though if you want it to be effective.