Using PostgreSQL and would like to have only admins have the ability to create new users. While allowing some non-admin users read-write access to our tables.
I cannot find a way to get this done. I have a role called webuser to which I gave:
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO webuser;
But now webuser has access to call CREATE USER and GRANT ROLE also. How can I remove access from webuser to do user-management operations while allowing SELECT, INSERT, UPDATE, DELETE on our database tables?
A user can only create other users if it has the createrole property: this property is not assigned by default when creating a user.
Doc. says:
CREATEROLE NOCREATEROLE
These clauses determine whether a role will be permitted to create new roles (that is, execute CREATE ROLE). A role with CREATEROLE
privilege can also alter and drop other roles. If not specified,
NOCREATEROLE is the default.
Either the user has been created with createrole or a superuser has run: alter user webuser createrole.
To revoke that privilege run alter user webuser nocreaterole
NB:
CREATE USER is now an alias for CREATE ROLE. The only difference is
that when the command is spelled CREATE USER, LOGIN is assumed by
default, whereas NOLOGIN is assumed when the command is spelled CREATE
ROLE.
Related
I am trying to create a group that has the right to create databases and roles. And then inherit these privileges with the next role. But the error constantly pops up that I don't have rights
Edited: (mistake between 'gg' and 'ggc', but steel doesn't work)
create role ggc with createdb createrole;
create user gg login password 'gg';
grant ggс to gg;
Always get this error: "SQL Error [42501]"
This way is also doesn't work
CREATE ROLE qwe WITH NOLOGIN CREATEDB CREATEROLE;
CREATE ROLE ads WITH LOGIN PASSWORD 'pass';
GRANT qwe TO ads;
SET ROLE ads;
CREATE DATABASE test;
This behavior is normal and is actually documented here:
The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actually SET ROLE to a specific role having one of these attributes in order to make use of the attribute. Continuing the above example, we might choose to grant CREATEDB and CREATEROLE to the admin role. Then a session connecting as role joe would not have these privileges immediately, only after doing SET ROLE admin.
You grant roles to users, not the other way round
I need to create a new firebird-db user which has only access to 4 specific tables. Is there a way to do that?
http://www.destructor.de/firebird/gsec.htm isn't really helpful in that regard.
The - third-party - gsec documentation you link does not provide information about granting rights on tables, because gsec is only for managing users in the security database. In Firebird, rights of users are managed in the individual databases using the GRANT (and REVOKE) statements (it is even possible to grant rights to users that do not exist (yet)). Be aware, Firebird 3 deprecated gsec, and since Firebird 2.5, it is recommended to use the SQL user management statements instead of gsec.
You need to create the user, and then give the user privileges to the tables you want. See the Security chapter in the Firebird 2.5 Language Reference.
A regular, authenticated user has no privileges on any database object
until they are explicitly granted, either to that individual user or
to all users bundled as the user PUBLIC.
Specifically:
Create a user:
create user <username> password '<password>';
See also CREATE USER; to create a user, you need to be either SYSDBA, or you need to have and the admin role in the security database, and the RDB$ADMIN role in the current database, and be logged in specifying the RDB$ADMIN role on connect.
Grant the necessary privileges to the user. For example to give SELECT privileges:
grant select on table <tablename> to user <username>;
To allow select, insert, update and delete:
grant select, insert, update, delete on table <tablename> to user <username>;
See also GRANT; to grant permission to an object, you must be either SYSDBA, the owner of the object, be RDB$ADMIN in the current database, or have been granted the privilege(s) with the WITH GRANT OPTION.
When you need to grant the same set of rights to multiple users, it is better to grant rights to a role, and then grant that role to the users. However in Firebird 3 and earlier, to get the rights granted to a role, the user needs to explicitly specify that role on connect (Firebird 4 will introduce roles that are automatically applied).
I have a client with a head-office, and various field offices.
I would like to grant a couple of head office people, who are SQL Azure contained users, the permission be become an "admin-lite". Specifically, I want them to be able to be able to create users, and make them in/active (with GRANT or REVOKE CONNECT).
I'd also like them to be able to assign other people to this same "admin-lite" role - they can then nominate one person in each branch who can create and manage their own users (there's quite a high turnover of staff).
The way I've made the first of the Head Office "admin-lites" is by making them a member of these two roles:
db_accessadmin - so they can create new users and issue GRANT or REVOKE CONNECT statements
db_securityadmin - so they can assign the new user to the appropriate role
Incidentally, they only need to be able to assign standard users to is a custom role, not a built-in role.
However, I've been able to make the first of these Head Office "admin-lites" because I'm a member of db_owners. As mentioned, I'd like them to be able to the same for their field offices - but I don't want to make the Head Office admin a member of db_owners, because this also gives them permission to make anyone else a db_owner too.
So, the question is, can I create a custom role with the permission to add people to db_accessadmin and db_securityadmin without them being a db_owner? Can I create a custom role with the same permissions as db_accessadmin and db_security admin that makes this easier, perhaps?
Thanks
If I am not wrong, you want to create a role which mimics the same functionality as db_accessadmin + db_securityadmin combined, but at the same time you do not want the members to be a member of db_owner.
Here is a role called FieldOfficeAdmin that does the same.
CREATE ROLE FieldOfficeAdmin
/* db_accessadmin permissions */
GRANT CONNECT to FieldOfficeAdmin ;
GRANT ALTER ANY USER to FieldOfficeAdmin ;
/* db_securityadmin permissions */
GRANT CREATE SCHEMA to FieldOfficeAdmin ;
GRANT ALTER ANY ROLE to FieldOfficeAdmin ;
GRANT CREATE ROLE to FieldOfficeAdmin ;
GRANT ALTER ANY APPLICATION ROLE to FieldOfficeAdmin ;
GRANT VIEW DEFINITION to FieldOfficeAdmin ;
Add any user(s) to this role, they will further be able to create more users and add them as members to the same role
CREATE USER fieldofficeadmin1 WITH PASSWORD = 'enterStrongPassword#1234';
GO
ALTER ROLE FieldOfficeAdmin ADD MEMBER fieldofficeadmin1
When you login as fieldofficeadmin1, you will be able to create more users and add them to the role
CREATE USER fieldofficeadmin2 WITH PASSWORD = 'enterStrongPassword#1234';
GO
ALTER ROLE FieldOfficeAdmin ADD MEMBER fieldofficeadmin2
But when you login as fieldofficeadmin1 and try to add a member to db_owner
ALTER ROLE db_owner ADD MEMBER FieldOfficeAdmin2
It should fail with the below error
Failed to execute query. Error: Cannot add the principal 'FieldOfficeAdmin2', because it does not exist or you do not have permission.
Please let me know if you have any further questions or if I interpreted your requirement incorrectly.
I'm attempting to create 4 different roles in Azure SQL database. The 4 role names are READ_ONLY_ACCESS, READ_UPDATE_ACCESS, READ_WRITE_UPDATE_ACCESS, FULL_ACCESS.
-READ_ACCESS - Grant Select
-READ_UPDATE_ACCESS - Grant Select, Update
-READ_WRITE_UPDATE_ACCESS - Grant select, Update, Insert
-FULL_ACCESS - Grant Select, Update, Insert, Delete
My goal is to create these 4 roles with these permissions, and then be able to create a user assigned to one of these roles. Example below of what I want to do after creating these roles:
CREATE USER username WITH PASSWORD = 'password';
ALTER ROLE READ_ACCESS ADD MEMBER username;
I've found a few sites that help with this, but I'm unclear as to whether or not I need to declare whether to deny access to certain permissions as well as declaring the granted access.
First create roles.
create role ApplicationUsers_ReadAccss;
grant select on schema::dbo to ApplicationUsers_ReadAccss;
create role ApplicationUsers_ReadUpdateAccss;
grant select, update on schema::dbo to ApplicationUsers_ReadUpdateAccss;
create role ApplicationUsers_ReadWriteUpdateAccss;
grant select, insert, update on schema::dbo to ApplicationUsers_ReadWriteUpdateAccss;
create role ApplicationUsers_FullAccess;
grant select, insert, update, delete, execute on schema::dbo to ApplicationUsers_FullAccess;
After that create logins and add them to one of the roles.
--create a server-level Login
create login AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
--add a user mapped to that login in each database
create user AppUser for login AppUser;
alter role ApplicationUsers_FullAccess add member AppUser;
I am trying to setup a new role for making the access rights granting easier. I was wondering if there is an easier way to give select on all tables (newly created tables should be accessible automatically) under a schema to selected users. I ran following queries for the same. But still my user is not able to access the specific table.
CREATE ROLE myrole;
GRANT SELECT ON myschema.mytable TO myrole;
GRANT usage ON schema myschema TO myrole;
CREATE USER mytest1 identified BY '***';
GRANT myrole TO mytest1;
After this, when I login with mytest1 user and trying to run select on myschema.mytable it is asking me to grant usage on schema to user. After I grant usage on schema to user directly it is failing with permission denied for that table.
Please help with the same. I am running on vertica 5.0
Update:
I find that u also have to make that role default or explicitely set that role as default for user session for making the role's effect take place.
ALTER USER mytest1 DEFAULT ROLE myrole;
But still, my another question of how to make all tables under a schema accessible to specific users remains.
As per the Vertica SQL Reference Manual.pdf (page 725) (doc version 5.0 - for page numbers)
GRANT (Schema)
...
USAGE
Allows the user access to the objects contained within the
schema. This allows the user to look up objects within the
schema. Note that the user must also be granted access to the
individual objects. See the GRANT TABLE (page 727) ... .
The the user must also be granted access to the individual objects means that you need to also GRANT table.
The two I use is GRANT SELECT and GRANT REFERENCES which allows the user to run queries and join (reference) tables in the query.
Example:
GRANT SELECT ON TABLE [schema].[Table1] TO myUser;
GRANT SELECT ON TABLE [schema].[Table2] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table1] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table2] TO myUser;
...
6.0 doc reference GRANT SCHEMA (page 808) and GRANT TABLE (page 813).