I have a database on SQL Server 2008 R2 that has two schemas, the default dbo and another one called Webapps, and both schemas are owned by dbo.
I created a view in the Webapps schema (Webapps.getInventory) that just does a simple select from dbo.Inventory. Then I created a user called Webuser that has SELECT permission to the Webapps schema.
Webuser can login and see the Webapps.getInventory view, but when it tries to select from it this error comes up:
The SELECT permission was denied on the object 'Inventory', database 'Database', schema 'dbo'.
I was thinking that since both schemas are owned by dbo, ownership chaining would allow the query to execute. The only way I seem to be able to get it to work is give Webuser permissions on dbo, or add it to the db_datareader role for the whole database. To me that seems to defeat the purpose of trying to separate things out into the Webapps schema if the user has to have read ability to everything else in the database.
So, am I overlooking something in my setup? Or is it correct that Webuser must have permission on both schemas in order for this view to work?
Eric I think you are "jumping" over a step in the ownership chain...
Have (another) look at this article: Ownership Chains Here is a snippet "Ownership chaining enables managing access to multiple objects, such as multiple tables, by setting permissions on one object, such as a view."
The chaining doesn't care that both schemas are owned by dbo, but rather that each login/user has appropriate permissions on object. So if you have a table owned by dbo that is included in a view where you have given select access to the webapps schema, then the users with access should have access to the table. The ownership chain isn't checked deeper than the fact that they can select against the view, no need to evaluate if they can select against the table.
So long story short, if you wrap the dbo.table in a view where webapps has select permissions then you should be good.
Hope that helps...
Another reason that cross-schema ownership chaining may break is if the schema owners were recently changed, e.g. setting them to the same owner specifically in order to use ownership chaining. You may need to drop and recreate the views (and add the permissions back) before it will work.
SQL Server caches various properties of views, and I saw a case where this caching appeared to be causing SQL Server to not realize that an object accessed by the view actually did have the same owner at that point. It gave a "permission denied" error on the object accessed by the view. Dropping and recreating the view fixed the problem. Rebooting the database server might have also fixed it, but that was not an option at the time.
SQL Server also allows individual objects to have specific owners different from the schema owner, and I confirmed that neither the view nor the accessed object had a separate owner set. I saw this in SQL Server 2012. Not sure if it's been fixed in newer versions.
I'm working on a DB2 for i database (aka DB2/400), on a schema (library) named S.
Inside schema S, I create database tables, procedures etc. with user A. I need that also user B has all privileges on such new objects. So I granted all privileges to users A and B on schema S. But new objects don't inherit them!
So I tried many configurations: on System i Navigator I played with authorization lists, "New Objects" button on permissions dialog for schema S... but nothing worked.
How can I set kind of default permissions to be automatically inherited by new objects created in my schema?
The only working alternative I know is remembering to grant privileges to user B every time I create an object. Not so smart...
Security is a large topic. It's normally handled by an administrator; someone who is aware of the larger ramifications of altering permissions to libraries.
There are several related settings to consider. Since you're trying to secure individual objects, you probably have restricted public authority either by setting QSECURITY to *EXCLUDE, or changing the library's CRTAUT to *EXCLUDE.
If we want ALL newly created objects in this library to have the same authority, consider an authorization list. I know that you said you played wuth authorization lists, but you didn't specify what you did.
Create an authorization list. Authorise user A and B to the authorization list. CHGLIB myschema CRTAUT(myautl). Now each object in myschema will have the same authority.
I have IBM i 7.1.
If I create table using 5250 emulator, inside STRSQL, it works, inheriting schema authorization list.
If I create table using iSeries Navigator V5R4M0 (neither with right click on Tables > New > Table, nor with cwbundbs.exe), it doesn't work. Authorization list is not inherited...
So it seems to be a bug in iSeries Navigator. Maybe someone with a newer version of it could confirm us if this has been fixed.
Full details in the chat with #BuckCalabro.
Hello and thank you for taking the time to read this,
I am mucking around in our sandbox and I am trying to find the best way to make our database more secure.
The issue we have is that we have 3 databases and we require information from each (using unions and views). We also have external shipping companies and merchants that need to have access to certain information in our database.
My thought was to create a separate database that had different merchant schemas (called MVIEW). Then create views within these schemas depending on what the merchants need. The views would then access the data from the other servers (the problem is that this would require the merchants to have SELECT permissions on the other servers etc.)
So at this point I thought it wise to create merchant schema's in each database and make views in there that would access the necessary information within the database, and then have the HVIEW database access those views. This way I could give the merchants select on just those schemas.
The problem still stands that the error says that the permission is denied and the user does not have access to the schemas that the view is trying to look at.
Do you have any suggestions?
Thanks again for your time.
Give them all access only to some views, but not to the data tables. And in the views, refer to the user login id. So behind the scenes, hidden within the view, you will be restricting their access with WHERE clauses
Example: select . . . . where supplierUser=SYSTEM_USER
Example: select . . . . where externalAccess=1 and SYSTEM_USER in (select names from tbl_externalUsers)
I am new to schema, roles and user management part in sql server. Till now I used to work with simple dbo schema but now after reading few articles I am intrested in creating schema for managing my tables in a folder fashion.
At present, I want to create a schema where i want to keep my tables that have same kind of functionality. When I tries to create a schema then I faces a problem while using query, permissions etc.
First of all i want to get used to of using schemas then only I want to explore it. But due to initial stages and work pressure as well i m not able to implement it yet.
What can i do to start using schema with default permissions as that of dbo.
Also let me know about creating roles and assigning roles on these schema. I want all this to be accessible by sa user itself at present.
What is the concept behind all these things
Basically
The schema has an owner
Objects in different schemas can access each other with no extra permissions if they have the same owner
Please see my question here: "SQL Server: How to permission schemas?" and RBarryYoung's enlightening answer...
I'm no beginner to using SQL databases, and in particular SQL Server. However, I've been primarily a SQL 2000 guy and I've always been confused by schemas in 2005+. Yes, I know the basic definition of a schema, but what are they really used for in a typical SQL Server deployment?
I've always just used the default schema. Why would I want to create specialized schemas? Why would I assign any of the built-in schemas?
EDIT: To clarify, I guess I'm looking for the benefits of schemas. If you're only going to use it as a security scheme, it seems like database roles already filled that.. er.. um.. role. And using it a as a namespace specifier seems to have been something you could have done with ownership (dbo versus user, etc..).
I guess what I'm getting at is, what do Schemas do that you couldn't do with owners and roles? What are their specifc benefits?
Schemas logically group tables, procedures, views together. All employee-related objects in the employee schema, etc.
You can also give permissions to just one schema, so that users can only see the schema they have access to and nothing else.
Just like Namespace of C# codes.
They can also provide a kind of naming collision protection for plugin data. For example, the new Change Data Capture feature in SQL Server 2008 puts the tables it uses in a separate cdc schema. This way, they don't have to worry about a naming conflict between a CDC table and a real table used in the database, and for that matter can deliberately shadow the names of the real tables.
I know it's an old thread, but I just looked into schemas myself and think the following could be another good candidate for schema usage:
In a Datawarehouse, with data coming from different sources, you can use a different schema for each source, and then e.g. control access based on the schemas. Also avoids the possible naming collisions between the various source, as another poster replied above.
If you keep your schema discrete then you can scale an application by deploying a given schema to a new DB server. (This assumes you have an application or system which is big enough to have distinct functionality).
An example, consider a system that performs logging. All logging tables and SPs are in the [logging] schema. Logging is a good example because it is rare (if ever) that other functionality in the system would overlap (that is join to) objects in the logging schema.
A hint for using this technique -- have a different connection string for each schema in your application / system. Then you deploy the schema elements to a new server and change your connection string when you need to scale.
At an ORACLE shop I worked at for many years, schemas were used to encapsulate procedures (and packages) that applied to different front-end applications. A different 'API' schema for each application often made sense as the use cases, users, and system requirements were quite different. For example, one 'API' schema was for a development/configuration application only to be used by developers. Another 'API' schema was for accessing the client data via views and procedures (searches). Another 'API' schema encapsulated code that was used for synchronizing development/configuration and client data with an application that had it's own database. Some of these 'API' schemas, under the covers, would still share common procedures and functions with eachother (via other 'COMMON' schemas) where it made sense.
I will say that not having a schema is probably not the end of the world, though it can be very helpful. Really, it is the lack of packages in SQL Server that really creates problems in my mind... but that is a different topic.
I tend to agree with Brent on this one... see this discussion here. http://www.brentozar.com/archive/2010/05/why-use-schemas/
In short... schemas aren't terribly useful except for very specific use cases. Makes things messy. Do not use them if you can help it. And try to obey the K(eep) I(t) S(imple) S(tupid) rule.
I don't see the benefit in aliasing out users tied to Schemas. Here is why....
Most people connect their user accounts to databases via roles initially, As soon as you assign a user to either the sysadmin, or the database role db_owner, in any form, that account is either aliased to the "dbo" user account, or has full permissions on a database. Once that occurs, no matter how you assign yourself to a scheme beyond your default schema (which has the same name as your user account), those dbo rights are assigned to those object you create under your user and schema. Its kinda pointless.....and just a namespace and confuses true ownership on those objects. Its poor design if you ask me....whomever designed it.
What they should have done is created "Groups", and thrown out schemas and role and just allow you to tier groups of groups in any combination you like, then at each tier tell the system if permissions are inherited, denied, or overwritten with custom ones. This would have been so much more intuitive and allowed DBA's to better control who the real owners are on those objects. Right now its implied in most cases the dbo default SQL Server user has those rights....not the user.
I think schemas are like a lot of new features (whether to SQL Server or any other software tool). You need to carefully evaluate whether the benefit of adding it to your development kit offsets the loss of simplicity in design and implementation.
It looks to me like schemas are roughly equivalent to optional namespaces. If you're in a situation where object names are colliding and the granularity of permissions is not fine enough, here's a tool. (I'd be inclined to say there might be design issues that should be dealt with at a more fundamental level first.)
The problem can be that, if it's there, some developers will start casually using it for short-term benefit; and once it's in there it can become kudzu.
In SQL Server 2000, objects created were linked to that particular user, like if a user, say
Sam creates an object, say, Employees, that table would appear like: Sam.Employees. What
about if Sam is leaving the compnay or moves to so other business area. As soon you delete
the user Sam, what would happen to Sam.Employees table? Probably, you would have to change
the ownership first from Sam.Employees to dbo.Employess. Schema provides a solution to
overcome this problem. Sam can create all his object within a schemam such as Emp_Schema.
Now, if he creates an object Employees within Emp_Schema then the object would be
referred to as Emp_Schema.Employees. Even if the user account Sam needs to be deleted, the
schema would not be affected.
development - each of our devs get their own schema as a sandbox to play in.
Here a good implementation example of using schemas with SQL Server. We had several ms-access applications. We wanted to convert those to a ASP.NET App portal. Every ms-access application is written as an App for that portal. Every ms-access application has its own database tables. Some of those are related, we put those in the common dbo schema of SQL Server. The rest gets its own schemas. That way if we want to know what tables belong to an App on the ASP.NET app portal that can easily be navigated, visualised and maintained.