Initially I could do everything in SSMS graphically, but now I am unable to ALTER table, create a KEY and CONSTRAINTS. I get the error message : "Unspecified error (MS Visual database Tools)". I only can do this now by TSQL.
I believe that my permissions were changed! I think I had permission db_owner and now I have
db_ddladmin, db_datareader and db_datawriter.
It's possible to do the commands above graphically with different permissions without having db_owner permission?
Regards
Elio
check under tools/options/designers/table and database designers
the option "prevent saving changes that require table re-creation" must be off
Related
What is the minimal permission needed on a sql server user/login for it to be able to run entity framework code first database migrations?
I naively would have thought that a user with the roles db_datareader, db_datawriter, Grant Alter on the Schema and Grant Create Table would be permissive enough.
On-Prem: SQL server with AD/sql login
you need the following permissions on the database.
[db_datareader]
[db_datawriter]
[db_ddladmin]
For full control over database use
[db_owner]
Azure Could: Azure SQL with ADD (Edit)
Please add [dbmanager] to master and user database.
Clearly it depends on what your migrations are/(will be) doing. For my use case, I ended up creating a shema, and restricting the user that the migration uses to the permissions below.
GRANT ALTER, INSERT, SELECT, DELETE, UPDATE, REFERENCES ON SCHEMA::schema_name TO migration_user
GRANT CREATE TABLE TO migration_user
I have a user who needs to rename a database. I could give dbcreator privileges, but this would allow the user to rename any database, and even create new ones.
So I tried to create a stored procedure that the user would call to do the job.
CREATE PROCEDURE SPMyRenameDB
WITH EXECUTE AS 'MySuperUser' -- MySuperUser is a SQL user with dbcreator permission
AS
ALTER DATABASE A MODIFY NAME = B
GO
I get an error :
The server principal "MySuperUser" is not able to access the database "A" under the current security context.
I tried with sp_renamedb, I get : User does not have permission to perform this action.
Even a simple SELECT statement to a table in database A is not allowed : The server principal "MySuperUser" is not able to access the database "A" under the current security context.
When I connect as MySuperUser and query the database A, it works as expected. (MySuperUser is a SQL user with dbCreator and sysAdmin privileges on the server).
I suspect that the "WITH EXECUTE AS" statement has some security restrictions that do not allow to use it outside of the current database.
The Stored Procedure is in a database (other than A and B) where the user has db_owner permissions.
Any suggestions ? I do not need to stick with my "WITH EXECUTE AS" approach. Anything that would do the trick is welcome.
Thanks,
Yves
Check ALTER DATABASE in MSDN -> Permissions
Requires ALTER permission on the database.
So just query as following
USE A
GO
GRANT ALTER TO 'someuser'
GO
User must be member of dbcreator server role. (MSDN documentation is wrong!).
What is the best way to prevent changes to a database or verify the integrity of this, so that it can not be altered from an application created for this database.
assuming you have a username and password to access the database permits reading - writing.
requirements:
The user has write permissions
Do not depend on a particular system like (MySQL, Oracle, SQL Server)
solution I'm looking for is not based on the user's permissions on the database
Most modern databases allow you to grant reading and writing permissions but while disallowing DDL commands like ALTER TABLE.
Do not give users that should not alter the DB structure permission to execute DDL.
If by "Alter" you mean change any data rows, rather than the database structure, you can grant the user only SELECT rights.
The user or account that your application uses must be granted permissions from the database server. Typically permissions include things like:
Select
Insert
Update
Delete
Alter
Drop
Only give the user account the permissions needed; in other words, don't grant Alter permission, and the application (or anyone using the same login) won't be able to alter tables.
Two strategies: 1) if you are running SQL Server, Oracle, DB2, etc, you can configure permissions so users are reader/writer by default (which means no alter permissions). 2) you can periodically check to see if someone has changed the data structure or even set up a DB trigger to detect changes and record who/when, etc (depends on your DB platform)
Could you please advise, what are permissions required to give user access to read Database diagrams in SQL Server 2005?
Thanks a lot!
From BOL
Although any user with access to a database can create a diagram, once the diagram has been created, the only users who can see it are the diagram's creator and any member of the db_owner role.
Ownership of diagrams can only be transferred to members of the db_owner role. This is only possible if the previous owner of the diagram has been removed from the database.
If the owner of a diagram has been removed from the database, the diagram will remain in the database until a member of the db_owner role attempts to open it. At that point the db_owner member can choose to take over ownership of the diagram.
So, db_owner/dbo is best
Try with this:
ALTER AUTHORIZATION ON DATABASE::AdventureWorks TO sa;
I've just found this in MSDN:
... you can grant execute premission on sp_creatediagram stored
procedure to someone who needs to create the diagram; you can grant
execute alter, rename or drop permisson as well. However, please note
that you still need related premission on tables, schemas otherwise
you may not be able to save the diagram. For instance, if you create a
new table in the diagram, you need CREATE TABLE permission on
corresponding Schema
less than db_owner/dbo
in my SQL2008 I have a user which is in the "db_datareader", "db_datawriter" and "db_ddladmin" DB roles, however when he tries to modify a table with SSMS he receives a message saying:
You are not logged in as the database owner or system administrator. You might not be able to save changes to tables that you do not own.
Of course, I would like to avoid such message, but until now I did find the way...
Therefore, I try to modify the user by adding him to the "db_owner" role, and of course I do not have the message above.
My question is:
Is it possible to keep the user in the "db_owner" role, but deny some actions like alter user or ? I try "alter any user" securable on DB level, but it does not work...
THANKS!
If the user is part of db_ddladmin it shouldn't be a problem. This is just a warning
Members of the db_ddladmin fixed database role can run any Data Definition Language (DDL) command in a database. It is probably just a warning from SSMS, try it out create a user and try to alter some tables
My understanding has always been that any user with db_owner rights can do anything to a database, up to and including dropping it. Certainly, this was true through SQL 2005. I've heard nothing to imply that this has changed with SQL 2008.
Those are indeed warnings, and I don't see any way to disable that type of warning in SSMS.
In 2008R2 the behavior I'm seeing is users with "db_datareader", "db_datawriter" and "db_ddladmin" still need to be granted view definition to be able to make edits in SSMS by right-clicking and selecting design. If you haven't granted view definition, then the design view will open (with warnings) read-only.
See: MSFT Connect Bug
To me it seems more discoverable to assign view definition permissions to your ddladmin users through a role, rather than doing it for specific user accounts as stated in the workaround on Connect. This will add a db_definitionviewer database role:
USE <DB Name>;
CREATE ROLE db_definitionviewer;
GRANT VIEW DEFINITION TO db_definitionviewer;
EXEC sp_addrolemember 'db_definitionviewer', '<DOMAIN\group> | <DOMAIN\User>';