I've been Googling for half an hour now, and can't seem to find the right place...
How do I add a user and grant that user access to all tables in the database? Found some GRANT snippets, but there is no mentioning of a password, so I assume that can be done on existing users only... But what about adding that user, and password identification?
PS: Not sure if it belongs more here, or on serverfault (neither has this answer already)... So feel free to move it, if it should be on serverfault instead.
It is two command in Pervasive SQL as well.
CREATE USER jsmith WITH PASSWORD password
GRANT SELECT ON * TO jsmith
Full documentation on both are in the SQL Syntax Reference guide on Pervasive's site.
One thing to note, most PSQL databases do not have security enabled by default and do not require a user to login. The CREATE USER and GRANT statements will return an error if you try to run them on a database that does not have security enabled.
It's 2 commands: CREATE USER and GRANT after.
From MySQL 5.0 Reference Manual
Normally, a database administrator
first uses CREATE USER to create an
account, then GRANT to define its
privileges and characteristics. For
example:
CREATE USER 'jeffrey'#'localhost' IDENTIFIED BY 'mypass';
GRANT ALL ON db1.* TO 'jeffrey'#'localhost';
Reference
Related
So, I'm trying to figure out how to properly administer a postgresql database.
I'm new with postgres and DBA in general.
I'm currently trying to have a dedicated role for a specific database.
I also want to have other user with a grant on that role so that I could do SET ROLE my_db_role and be able to manipulate this specific database from there.
However, I've got permission leakage, meaning that I can manipulate my database without having to do this SET ROLE my_db_role command.
Here are the commands I do to get my unssuccessful result :
=# CREATE ROLE test NOINHERIT;
=# CREATE USER myuser;
=# CREATE DATABASE test OWNER test;
=# \c test
=# DROP SCHEMA public;
=# CREATE SCHEMA AUTHORIZATION test;
=# GRANT test TO myuser;
=# \c test myuser
=> CREATE TABLE test.mytable(id integer);
CREATE TABLE
Temps : 46,469 ms
Why did the last commands succeeded ?
In my opinion, myuser should have no right on test database/schema, as test role has the NOINHERIT flag, so this CREATE command should not be possible.
It should need to do SET ROLE test to succeed which is not the case here.
What am I missing ?
On a side note, I have a hard time finding good source of information on how to administer properly postgresql apart from the official doc. If you can share some good material about it, you're more than welcome.
I'm afraid I don't know of any particularly good resource covering role management and administration. The standards here show all the signs of having to please several stake-holders and are flexible but confusing.
As to your immediate question though, the issue is that the "NOINHERIT" is on the wrong role. However, this feature is not really a security constraint.
test=# ALTER USER myuser NOINHERIT;
test=# \c - myuser
You are now connected to database "test" as user "myuser".
test=> CREATE TABLE test.mytable(id int);
ERROR: permission denied for schema test
LINE 1: CREATE TABLE test.mytable(id int);
^
test=> SET ROLE test;
SET
test=> CREATE TABLE test.mytable(id int);
CREATE TABLE
As you can see, myuser doesn't inherit the permissions of test but there is nothing to stop you switching directly to that role.
If you find this fiddly and confusing, then you are far from alone. I find it useful to add some tests to check any configuration I set up.
Because test is the owner of the database, it basically have all privileges on it on its subsequent objects.
As pointed out by #Richard Huxton setting NOINHERIT on test role prevent it to inherit form other roles, but does not prevent its privileges to be inherited to another roles.
When you issue:
GRANT test TO myuser;
You just grant the same privileges as the owner to myuser, therefore myuser can create object, actually it can do whatever the owner can.
It is not an issue of PostgreSQL it is the way ownership works. Anyway you can explicitly revoke privileges from owner (eg. not destroying an important object by mistake).
But you should consider other Privileges Policies for the role myuser, making it not inheriting from the owner but granting what it needs only. If the user can create a table, it should be blessed with:
GRANT CREATE ON SCHEMA test TO myuser;
I understand you are bit disappointed with PostgreSQL Privileges Management, at the very begging it can seem hard to understand through the documentation. To better learn how it actually works, you should issue:
REVOKE ALL ON DATABASE test FROM public;
Then all roles will need explicit privileges to CONNECT and SCHEMA USAGE. You will then discover the dependencies between objects and privileges. Reading more and more the GRANT page should be enough even if it is succinct.
About the SET ROLE security "issue", it is limited to all roles the current role is member of:
The specified role_name must be a role that the current session user
is a member of. (If the session user is a superuser, any role can be
selected.)
Therefore an user cannot override its privileges, it just can endorse other identity it has been granted with.
I am learning oracle and PL/SQL. I have created a database called "PRACTICE" and created a user called "MITHRA" by connecting as a SYS.
My question is i want to grant privileges to the user "MITHRA" for the specific database "PRACTICE". The user "MITHRA" can able to do all activities like create, drop, alter etc.. only in "PRACTICE" database.
Please suggest me how to do this.
Oracle can only host one database so what you are asking for will essentially grant root privileges to this user, including drop database. This should be avoided on production from obvious reasons.
So in order to grant full access to user mithra:
Connect as sys and run the following command -
Grant dba to mithra;
That should give the user mithra all possible privileges for that database.
You can also use the grant command the grant any distinct privileges.
Just to be sure that we speak in the same terms.
Is the "PRACTICE" database or schema? If it is DATABASE then you should grant DBA, if it is schema then Oracle does not have statements to grant rights to schemas (only system and object priveleges). Reading your question makes me think that you come from MSSQL where you can grant to a specific user gratns to specific database, in Oracle it is a little bit different - to make an analogy - you do not have databases but schemas.
I am trying to add permissions to a Store procedure for a user using this query,
USE [MyDatabaseName]
GO
GRANT EXEC ON [dbo].[StoreProcedureName] TO [UserName]
GO
I can give permissions to user through theUser Interface but using this query I get this error,
Cannot find the user 'UserName', because it does not exist or you do not have
permission.
If I don't have permissions then how can I add permissions using User Interface.
I just encountered the same problem.
Make sure there is a user mapping for your login in the master table. No database role memberships are required, just tick 'Map' for the database master under 'User Mapping' in the properties for the login 'UserName'.
Run this:
USE [db_where_you_need_access]
GO
CREATE USER [your_user] FOR LOGIN [your_user]
I had this issue and yet I am in the local admin group on the server. Apparently if UAC is turned onrunning SQL Server Management Studio as administrator makes a world of difference. I didn't have any permissions until I did this.
You can get problems like this when a database has been restored from another server and the GUID of the user in the database is different from that of the current server.
This will re-link orphaned users:
USE <database_name>;
GO
sp_change_users_login #Action='update_one', #UserNamePattern='<database_user>',
#LoginName='<login_name>';
GO
other than this, if the user exists and you have the relevant security rights, there is no reason what you doing wouldn't work.
A bit of a daft one, but make sure your UserName is spelt correctly in the GRANT statement. I spent half an hour trying to figure out what the cause of this error was and it was simply a typo on my part!
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>';
I have a SQL Server 2005 database that I'm trying to access as a limited user account, using Windows authentication. I've got BUILTIN\Users added as a database user (before I did so, I couldn't even open the database). I'm working under the assumption that everybody is supposed to have permissions for the "public" role applied to them, so I didn't do anything with role assignment. Under tblFoo, I can use the SSMS Properties dialog (Permissions page) to add "public", then set explicit permissions. Among these is "Grant" for SELECT. But running
SELECT * from tblFoo;
as a limited (BUILTIN\Users) account gives me an error "Select permission denied on object 'tblFoo', database 'bar', schema 'dbo'". In the properties dialog, there's an "Effective Permissions button, but it's greyed out.
Further, I tried creating a non-priv account called "UserTest", adding that at the server level, then mapping it down to the "bar" database. This let me add UserTest to the "Users or Roles" list, which let me run "Effective Permissions" for the account. No permissions are listed at all -- this doesn't seem right. The account must be in public, and public grants (among other things) Select on tblFoo, so why doesn't the UserTest account show an effective permission? I feel like I'm going a bit crazy here.
ASIDE: I am aware that many people don't like using the "public" role to set permissions. This is just my tinkering time; in final design I'm sure we'll have several flexible (custom) database roles. I'm just trying to figure out the behavior I'm seeing, so please no "don't do that!" answers.
UPDATE: Apparently I know just enough SQL Server to be a danger to myself and others. In setting permissions (as I said, "among others"), I had DENY CONTROL. When I set this permission, I think I tried to look up what it did, had a vague idea, and decided on DENY. I cannot currently recall why this seemed the thing to do, but it would appear that that was the reason I was getting permission failures. So I'm updating my question: can anyone explain the "CONTROL" permission, as it pertains to tables?
You only need to have SELECT rights. In raw SQL (see the "script" icon/button in your dialogue box), it's GRANT SELECT ON dbo.tblFoo to public. This is the only permission needed to view the data,
In this case, the error message explicitly mentions "deny". "DENY" is a right in itself, so it mentions it,
If you had no rights, you'd get the message (very approximately) "tblFoo does not exist or you do not have rights"
"DENY CONTROL" is mentioned here. In this case, you denied all rights to the public role.
The grantee effectively has all
defined permissions on the securable
Assuming "UserTest" is a domain user account, connect as a member of the sysadmin role and run
EXEC MASTER.dbo.xp_logininfo 'Domain\UserTest', 'all'
(substituting your domain name for "Domain")
this will display the Windows groups etc. that the account is inheriting security permissions from and the level of access, e.g. you would expect to see something like:
account name type privilege mapped login name permission path
domain\usertest user user domain\usertest BUILTIN\Users
This will help troubleshoot where the account is inheriting permissions from, e.g. which Windows groups it is part of that have permissions to the database. If this all looks OK then I would follow your own advice and not mess with the public role.
Create a database role in your
database
Assign explicit permissions for that
role
Create a server login for your user
account
Open the server login, go to the
User Mapping section, click on the
database and select the database
role you created