I have been using PostGresSQL as the database for one of my applications. To support multi-tenancy, I used schemas and roles for each tenant so as to limit access and prevent data leaks in event of an SQL injection. I am maintaining a single connection pool and then doing a SET ROLE after determining the tenant context so he can access only his own schema. This all works well. However, what is the equivalent design in mySQL ? I saw that mySQL does not have "roles" and a schema / database is the same conceptually, how can I achieve something similar in mySQL ? I ask because I am designing another application and am being told to use mySQL instead of PGSQL.
Thanks
Since mysql does not have the concept of roles, you either have to use different mysql database users and databases to achieve the same logical separation of data. Effectively, after determining the context, you have to connect to mysql using a different myswl user account and a different default database. The drawback is that this solution will render connection pooling inert. Fortunately, in MySQL establishing a new connection to the database is quick and does not require too much resources.
Alternatively, you can use a single database and mysql user account and distinguish between you users on application user account level. Obviously, this means that your users' data will not have the same logical separation as you currently have, but you can still use connection pooling.
As a third alternative with limited number of users you can use the same mysql user account and default database to connect to mysql, but store actual user data in separate databases only accessible using separate mysql user accounts. However, in that default database create separate views for each and every table in the user databases. In the create view statement set the definer clause to the mysql user account that can access the given database where the table is stored and set sql security clause to definer. This way you can still use connection pooling, since the connections are made using a common user id to a default database. The client data will be logically separated in the databases. The drawback is that through the views within the default database all data will be accessible and any modification to the underlying data structure must be reflected in the views as well.
I am getting the following error
Cannot execute as the database principal because the principal "dbo"
does not exist, this type of principal cannot be impersonated,
or you do not have permission.
I read about ALTER AUTHORIZATION, but I have no idea what database this is happening in. This error is getting spit out very frequently, and grows the error log by about 1GB every day.
I resolved this issue by setting database owner. My database did not have had any owner before this issue. Execute this command in your database to set owner to sysadmin account:
use [YourDatabaseName] EXEC sp_changedbowner 'sa'
Do Graphically.
Database right click-->properties-->files-->select database owner-->select [sa]-- ok
USE [<dbname>]
GO
sp_changedbowner '<user>' -- you can use 'sa' as a quick fix in databases with SQL authentication
KB913423 - You cannot run a statement or a module that includes the EXECUTE AS clause after you restore a database in SQL Server 2005
After restoring a Database from SQL2016 to SQL2019, I had the same issue when I try to access Database Diagrams. I had the correct Database owner already but owner of Files was empty. Once I set that, it worked properly...
This may also happen when the database is a restore from a different SQL server or instance. In that case, the security principal 'dbo' in the database is not the same as the security principal on the SQL server on which the db was restored.
Don't ask me how I know this...
another way of doing it
ALTER AUTHORIZATION
ON DATABASE::[DatabaseName]
TO [A Suitable Login];
Selected answer and some others are all good. I just want give a more SQL pure explanation. It comes to same solution that there is no (valid) database owner.
Database owner account dbo which is mentioned in error is always created with database. So it seems strange that it doesn't exist but you can check with two selects (or one but let's keep it simple).
SELECT [name],[sid]
FROM [DB_NAME].[sys].[database_principals]
WHERE [name] = 'dbo'
which shows SID of dbo user in DB_NAME database and
SELECT [name],[sid]
FROM [sys].[syslogins]
to show all logins (and their SIDs) for this SQL server instance. Notice it didn't write any db_name prefix, that's because every database has same information in that view.
So in case of error above there will not be login with SID that is assigned to database dbo user.
As explained above that usually happens when restoring database from another computer (where database and dbo user were created by different login). And you can fix it by changing ownership to existing login.
Under Security, add the principal as a "SQL user without login", make it own the schema with the same name as the principal and then in Membership make it db_owner.
Also had this error when accidentally fed a database connection string to the readonly mirror - not the primary database in a HA setup.
As the message said, you should set permission as owner to your user. So you can use following:
ALTER AUTHORIZATION
ON DATABASE::[YourDBName]
TO [UserLogin];
Hope helpful!
Leave comment if it's ok for you.
In my case I got this error when trying to impersonate as another user. E.g.
EXEC AS USER = 'dbo';
And as the database was imported from another environment, some of its users did not match the SQL Server logins.
You can check if you have the same problem by running the (deprecated) sp_change_users_login (in "Report" mode), or use the following query:
select p.name,p.sid "sid in DB", (select serp.sid from sys.server_principals serp where serp.name = p.name) "sid in server"
from sys.database_principals p
where p.type in ('G','S','U')
and p.authentication_type = 1
and p.sid not in (select sid from sys.server_principals)
If in that list shows the user you are trying to impersonate, then you probably can fix it by assigning the DB user to the proper login in your server. For instance:
ALTER USER dbo WITH LOGIN = dbo;
Go to the Properties - Files.
The owner name must be blank. Just put "sa" in the user name and the issue will be resolved.
I'm trying to set up a user in SQL Server 2008 R2 so when they login, they only see one database and so they only see views with 1 schema.
They should not be able to see that other databases exist, that any tables exist within the database that they can see, or any views that exist other than tables that belong to one schema.
How can I go about doing this?
Thank you in advance
Edit: some more information. I have managed to get a user to only see 1 database and no others in the past by denying view all databases and making the user the owner of the database. In this case the user can not be the owner of the database.
You can move the database to a new instance.
I am using MSSQL 2008 R2. I have a particular database that when it is restored it is being accessible from everyone from the SQL Management Studio. By using the below SQL statement I have identified that the Public server role has been granted the connect permission on this database.
use db_mydb
SELECT *
FROM sys.database_permissions
WHERE grantee_principal_id = (SELECT principal_id
FROM sys.server_principals
WHERE name ='public')
With the result of this query being the below
0 DATABASE 0 0 2 1 CO CONNECT G GRANT
Is there any work around to revoke this permission?
One of the correct ways would be
Run DROP USER all users in the database
Run DENY CONNECT TO those users
Don't mess with public
Your code is misleading you too:
The server level public role is unrelated to the database level public role
sys.database_permissions.grantee_principal_id refers to sys.database_principals
For roles, there is no common column between sys.database_permissions/sys.database_principals and sys.server_principals
My solution for this was to create an empty database. Then script the tables, views and stored procuders using the Generate Scripts. And then import the data using the Import Data option. All of this can be done using only the Micosoft SQL Management Studio.
In my SQL Server 2005 server I create databases and logins using Management Studio. My application requires that I give a newly created user read and write permissions to another database.
To do this I right-click the newly created login, select properties and go to User Mapping. I put a check beside the database to map this login to the db and select db_datareader and db_datawriter as the roles to map.
Can this be done programmatically? I've read about using Alter User and sp_change_users_login but I'm having problems getting these to work, since sp_change_users_login has been deprecated so I'd prefer to use Alter User.
Please note my understanding of SQL Server database users/logins/roles is basic
Logins are for the server instance. Users are at the database level. Roles are generally found at the database level but there are some fixed roles like sysadmin at the server instance level.
Go here for the grammar to create a user on a database.
Go here for the syntax for adding that user to a database role.
You are likely going to execute something like the following to accomplish all of this.
Create Login temp1 with Password = '123!##$FAF', Default_Database = test
GO
use test;
Create User user_blah1 from Login temp1
GO
use test;
Exec sp_addrolemember #rolename = 'db_datareader',
#membername = 'user_blah1'