Why does SQL Server create schemas for the initial DB roles, such as db_accessadmin, db_datareader, etc.? I understand the roles and why they exist, but I don't understand why they are given schemas when the database is created. Does anybody use them? I can't imagine that Microsoft recommends adding tables to them. I can't see adding an employee or product table to db_datawriter. Are there some kind of hidden system objects owned by them?
Others have said legacy/backwards compatibility without really explaining it.
When SQL Server 2005 was introduced, they introduced user/schema separation. Before that time, each user and role implicitly had a schema of the same name associated with it (and there was no way to create schemas, other than by creating users or roles).
So, for those built in roles that existed in the 2000 (or earlier) versions of SQL Server, there was always a schema "available" in the database with the same name as that role. So some code may have been written assuming that such schemas existed; later versions of SQL Server ensure this is still true, to avoid breaking such code.
Legacy.
You should use explicit GRANT (say GRANT ALTER USER TO ...) rather then using the legacy fixed database roles.
If you use sp_grantdbaccess you also get a schema created: you should be using CREATE USER
Related
From what I read so far, the WL 6.1 documentation does not much care of this, and it's assumed that database user ID is SYSADM or something like that. Also, I did not see any explicit explanation what privileges the user ID must have.
While SYSADM is fine for development or staging environment, for production is desired to allow the DB user as less as possible, on the other hand I don't wish to get some exceptions related to weak permissions.
Is there any documentation or other source which explicitly mentions/explains what permissions DB2 user ID must have for Worklight 6.1 datasources?
UPDATE: My understanding is that for WL application work (not install) must be used a separate DB user (mostly for security reason, give as less as possible permissions in production). My question above refers to that "application" DB user. It's clear that create tables and schemas activity can do any DB ID, including SYSADM, which is overkill to further work.
I am asking about DB2 user which configured in WAS datasources, once someone else created DBs, schemas and tables.
The DB2 user used to connect to the datasources need not have any special privileges other than to be able to connect to the Worklight databases. The DB2 user that is used to actually create and initially populate the databases must have SYSADM or SYSCTRL privileges, but these are not needed once the database is set up.
There is more information in the documentation, here: Creating the DB2 databases
The documentation defines the privileges required for a user that can create the tables at install time, upgrade the tables for a new Worklight version and use them at runtime.
At runtime, you need, for each table created: SELECT, UPDATE, INSERT, DELETE. And you need to be able to select a SEQUENCE.
The list of tables and SEQUENCE for Worklight can be found in
/WorklightServer/databases/create-worklight-db2.sql and create--worklightreports-db2.sql
So I wanted to know if there is an acceptable method to Allow SQL Injection.
Example:
Limit permissions on the table(s)/database(s)
Why you ask?
My employer wanted to devise a way to test the skills of applicants, one suggestion was to allow resume submissions via SQL Injection.
Any thoughts? suggestions?
You could use roles. Create a role for the web application (or whatever) that is used to connect to the database. Limit this role to only permit INSERT and access to necessary tables for applying. Applicants with access to your database through the application could then only use SQL injections to add their resume.
It may be possible for someone more talented in SQL to use injections in a way that increases the role's permission. But I think if the role had limited access to only specific tables and didn't have CREATE or GRANT privileges, the user wouldn't be able to create new roles.
Here is some information on roles to get you started:
Adding Roles to MySQL with MySQL Workbench
Creating Roles in PostgreSQL
GRANT command - used to add privileges to users on table, database, etc. This page is for PostgreSQL, but MySQL is very similar (see this SO answer)
Given that the reason behind this is to test people's ability, create a database with data you can afford to lose. Set up a form that posts to a coldfusion or php or java or .net or some other type of page which connects to that database.
On the form, put a textarea and submit button. On the form target page, log what they put in the textarea. Compare the log to the database to see how it turned out.
Then test to your heart's delight.
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 am not a DBA and so dont really know anything about SQL 2005 security settings, etc. I am attempting to set up an empty copy of our database by generating the full database from SQL Management Studio generated scripts. Unfortunately I don't know what many of the options do and the MSFT documentation of this processes isn't great.
There is an option to generate script for Schemas, Tables, Views and Users. It is the users I am confused about, because I don't understand how they affect the usage of the database. We have some developers in the team who are in this list and some who are not, yet everyone can do anything on the database, at least when they are hosting it on their own machines.
Do I need to keep these Users in my new generated database and what do they do?
We also have a dbo User who is a db_owner and owns many of our schemas. What is this dbo User? What is the significance of a user Owning Schemas? We use Schemas as "namespaces" to group logically related tables in our database but I take it there is more to them than that?
There is also a username tied to this dbo User, its the windows NT login of one of our developers, but he doesn't have his own User object in the list...is there any significance to this? Is this a bad thing?
Other Users are guest, INFORMATION_SCHEMA and sys, but I think these are all defaults?
Sorry but I am a SQL admin ignoramus and usually left these things to the DBA in my previous job!
Thanks for any help.
Do I need to keep these Users in my new generated database and what do they do
The answer is it depends. If your applications use a mixed mode authentication then you will need the user accounts created in SQL. If you use windows authentication (and it sounds like you are) then you might not need them.
What is the significance of a user Owning Schemas?
In SQL Server 2005 all schemas must be owned by a user. Schemas can be used to group functionality but they can also be used to group security. For example a user account may only have access to a specific schema (or multiple schemas).
Hopefully that helps answer some of your questions
By default, objects (tables, stored procedures, etc) are set up with the dbo owner/schema (I think ms sql 2000 calls it owner, while ms sql 2005 calls it schema)
The owner/schema is really a role or user in the database. I've always left the default of dbo, but I've recently seen some examples in microsoft training books where some of their tables & stored procedures had different owners/schemas. When is it beneficial to do this and why?
The use of schemas is exceptionally beneficial when you have security concerns.
If you have multiple applications that access the database, you might not want to give the Logistics department access to Human Resources records. So you put all of your Human Resources tables into an hr schema and only allow access to it for users in the hr role.
Six months down the road, Logistics now needs to know internal expense accounts so they can send all of these palettes of blue pens to the correct location people. You can then create a stored procedure that executes as a user that has permission to view the hr schema as well as the logistics schema. The Logistics users never need to know what's going on in HR and yet they still get their data.
You can also use schemas the way cfeduke has suggested and just use them to group things in the object browser. If you are doing this, just be careful because you might end up creating Person.Address and Company.Address when you really just need a single dbo.Address (I'm not knocking your example, cfeduke, just using it to illustrate that both address tables might be the same or they might be different and that YMMV).
I've used schemas in the past sort of like namespaces so you could have multiple entities named Address ([Person].[Address], [Company].[Address]). The advantage to this is visual organization in SQL Management Studio, you can get the same thing by putting everything under one schema and naming tables with a single identifier (i.e. [dbo].[PersonAddress]).
I've also used them for developer vs. developer development prior to running SQL Server Developer Edition on all our dev machines (back when we had a centralized development database earlier in my career).
In SQL 2000 the Schemas where equivalent to database users, in SQL 2005 each schema is a distinct namespace that exists independently of the database user who created it.
I use schemas when I need to make features or modules that will be maybe used later in other projects, so I will be able to isolate the database objects that are used by the module.
Organization
In a dev environment, the production copy of the objects are dbo but developers can develop in their own schemas. Then code can reference the prod copy or their changes very simply. Using aliases can make this technique even more simple.
Also, a production database might support numerous systems or subsystems. You can use distinct schemas to keep those objects grouped.
This article explains it well, including the changes from SQL Server 2000 to 2005.