I am learning Snowflake with a trial account and all the default databases were visible however, I logged in today and can see only one default database visible viz. SNOWFLAKE_SAMPLE_DATA. I am logged in as ACCOUNTADMIN and don't see a reason why. Is anyone aware if this is a recent update for trial account holders or this is some setting for the same?
The Default databases should be available and probably the context is not set correctly after you login.
I see that you mentioned that you logged in as a ACCOUNTADMIN. This role should have the privileges to view all the databases available in the account. Click on the Database tab and you should see all the databases listed.
From the worksheet, you can select the role (by default it will be sysadmin) change this to accountadmin. Once this is done, when you click the dropdown it will list all the databases from where you choose the correct database and schema.
Other way is to run the commands manually like
use role accountadmin;
use warehouse testl;
use database SNOWFLAKE_SAMPLE_DATA;
use schema public;
Hopefully, this will help you in future. Thanks
Related
What harm can a user with GRANT SELECT ON database.dbo.view TO User access can do? The user can see Security folder in SSMS, roles and can also see master database, roles, etc.? Is there a way we can restrict the user to not see or modify any security roles/groups but can see only a view?
Many Thanks!
In SSMS, a new user will not see the database tables/views without proper roles/permission provided to them but they can see the database objects like Security Users, schema or Roles etc., however they still cannot perform any actions on them if they don't have proper permissions granted to them. As an example if you created a new user and granted a select for a single view, that user will just be able to Select from the view and not able to do anything else on it like altering/deleting the view. Also same user can see the security objects but cannot make any changes on them as well.
We can hide the databases from user in SSMS by using below statement but this is going to hide all the database(even the database in which user has access to see the view).
DENY VIEW ANY DATABASE TO <login name>
While exploring Snowflake documentation on Audit Logging (user login history, object creation/deletion, query execution history etc), I found the below information.
But in my trail account, I didn't find any shared DB with name 'SNOWFLAKE'.
Would apreciate if someone can throw more light on this feature.
Neeraj
You need to choose the 'ACCOUNTADMIN' role in the context of your session to see that database.
You should set the ACCOUNTADMIN role in the context to access the SNOWFLAKE database.
Alternatively, As accountadmin, you can grant the privilege for viewing the data to other users as below.
Grant imported privileges on database snowflake to ; -- where is an existing/new role granted to
Changing the role in right upper corner is not sufficient. Yo uneed to change the role in the context.
After that, 'SNOWFLAKE' shared DB will be visible.
I have been searching for articles and SQL script examples that would demonstrate how to securely and conveniently solve one of the most common scenarios - connecting from a .Net Core Entity Framework based web application to an SQL database.
But somehow I could not find any coherent step-by-step guide from a reputable source.
Let's assume the following:
I cannot use integrated Windows auth in the connection string and must use username and password based auth (because hosting on a Linux server and the DB is on a different Windows server)
the web service will need your usual minimum set of permissions - connect to the database, read data, write data, delete data, execute stored procedures
While reading many tutorials, I find there are multiple ways to manage the connection permissions. To avoid this question being too broad, I'll list my current choices as I understand them (please correct me if I'm missing something).
Users and logins:
create a login and a user for the database
create a database-only user without a login (not sure if this is applicable to a web app and connection string, but still it's a feature that I've seen being used)
Assigning permissions:
assign the user to some fixed SQL role (db_datareader, db_datawriter AND also will have to grant EXECUTE permission)
grant all fixed permissions
create a custom role (let's say, db_web_apps) with required permissions
Which choices are better (more secure and easier to manage in general) and recommended by SQL DBAs?
I think every database administrator should have a template script handy for quickly adding a new user with minimum required permissions every time when developers ask for a new connection for their shiny new web app.
If you know a good, reliable tutorial or GitHub / Gist example that explains what and why is being done that way or a script that you yourself have used for years without any issues in production environments, I'll really appreciate if you could share it.
Create a role in the database and assign the required privileges to the role. Don't use the fixed database roles. Instead grant permissions directly to objects, schemas, or the entire database if necessary. Like this:
create role trusted_app_role
grant select, insert, update, delete, execute
on schema::dbo to trusted_app_role
That will grant the role full DML permissions on all the objects in the default dbo schema. So if you have any tables or procedures you don't want the app to have access to, just create them in a different schema, say, admin. This way you never have to fiddle with permissions as you add objects. The fixed database roles predate schema-based permissions, and aren't really needed any more.
For your application's identity, add Active Directory or Azure Active Directory (Azure SQL) identities to this role, or, if you can't, add SQL Users to the role.
If you are on Azure SQL, you should normally use a database user without a login. On SQL Server you can only add "contained database users" if you enable Partial Database Containment. Which you can do, but is incompatible with Change Tracking and Change Data Capture, so it's a tradeoff.
So normally for SQL Server you still create a login and map the user to the login. EG:
create login web_service_user with password = '5X+jeuAB6kmhw85R/AxAg'
create user web_service_user for login web_service_user
And then add that user to your role
alter role trusted_app_role add member web_service_user
I want a user to log-in to SQL server and only see one database. This user can not be the database owner.
I have tried doing DENY VIEW ANY DATABASE TO [username]
and i would now like to GRANT to view a single database to [username]
is this possible? how do i do this?
Thank you.
edit: to clarify what i mean, i dont want the user to even see that other databases exist, not just that they cant go into the database.
thanks!
I assume you are talking about SQL Server Management Studio here. In short, if you are unable to grant DBO to the user (which is perfectly understandable) then there is NOT currently a way to accomplish what you want.
You've gotten as close as you'll get by issuing
DENY VIEW ANY DATABASE TO <customerlogin>
effectively hiding all databases from the user. Without making the user a DBO there is no way to open view ability back up to only one. This is not a feature that has ever been added per Mike Hotek well known SQL Expert.
You can see a much longer and more detailed discussion regarding this desire on this MSDN thread.
http://social.msdn.microsoft.com/Forums/en/sqlsecurity/thread/a989ca87-660d-41c4-9dac-70b29a83ddfb
After you deny view to any database to a specific user:
DENY VIEW ANY DATABASE TO <customerlogin>
If you make this user a db_owner for the specific database:
USE <customdatabase>
exec SP_changedbowner <customerlogin>
It will only be able to see and use the chosen database.
More details:
https://www.mssqltips.com/sqlservertip/2995/how-to-hide-sql-server-user-databases-in-sql-server-management-studio/
Here is the scenario. I have a SQL Server 2005 production database/server. It currently has developers and supporters who can connect to it. I need to create a security module that gives developers read-only access to all areas of the database. This means that a developer should be able to view all objects as well as scheduled activities/jobs only.
Is it possible to enable security in this way and if so can I be gently guided on how to achieve this. I am learning to be a DBA and creating snapshots of the databases are not an option.
Thank you all in advance.
There is permission to every object.
Create a stored procedure that grant each gruop the exact permission you need on the objects you need to protect.
I'm not quite sure I follow where this "security module" will be in the architecture. Anyhow, here's one possibility that secures it from the database end.
I'm going to assume you already have users created.
Create a new role (yourdb > security > roles > new database role), say "ReadOnlyDevelopers". Make the owner dbo or whatever makes sense. Do not select any schemas to be owned by the role. Populate the "Role Members" with your developers.
Next, open the properties page on your database. Go to the permissions page. Click Add... and add the new role. Under the permissions grid at the bottom, Grant SELECT to the role.
Now assuming your developers already belong to some other role, you'll need to go into the user properties and under Database Role Membership restrict them to just the new role. At this point they should be able to just read
I'm guessing that I'm missing a detail or two (the role may need to be grated a few additional rights to "see" the database, alter passwords, etc.) but I can't get to that level of detail without setting up the entire scenario. Hopefully this pushes you in the right direction.