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
Related
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.
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.
How can I change a username in Informix?
select * from sysusers; lists below
username John.Doe
usertype R
priority 5
password
defrole admin
I want to update the username to be in lowercase for user john.doe but seems we cannot just run an update on it update sysusers set username = xxx as usual. What command should we use to do this?
Someone ran:
GRANT RESOURCE TO "John.Doe";
You will need to to revoke their RESOURCE privilege:
REVOKE RESOURCE FROM "John.Doe";
but that leaves John.Doe with CONNECT privilege, which you will also need to revoke. If you revoke DBA privilege from someone, they retain CONNECT privilege too (and not RESOURCE privilege).
REVOKE CONNECT FROM "John.Doe";
Then you can re-grant the RESOURCE privilege to the user name in lower-case:
GRANT RESOURCE TO "john.doe";
Note that the username must be quoted each time, both to conserve case-sensitivity and because neither john.doe nor John.Doe is a valid identifier because of the . in the middle.
These changes only affect the SysUsers table. Any resources created by John.Doe are still owned by John.Doe and not by john.doe. There is no way to change the ownership of objects. The 'workaround' is to drop and recreate the objects with the correct owner. Beware that dropping an object loses all permissions granted on the object, and also destroys views built on top of the dropped table (or view).
You cannot. Despite the catalog table name, entries in that table represent the Informix database level privileges for that user, not the actual user. It is the GRANT and REVOKE SQL commands that manipulate those entries.
The only way I can think is to REVOKE all database privileges for user John.Doeand GRANT the same privileges to the user john.doe. Note that any object owned by user John.Doe will continue to belong to John.Doe.
I have an oracle database with two roles assigned to the same user.
The user will connect from .Net application.
Since each role has its own privileges I would like, when using my application, only one role to be considered. So the user will choose the role to be considered when logging to the application. And the privileges related to the other role wont be "active".
for example
Role 1 can access Table A
Role 2 can access Table B
So theoretically The user can access A & B
When using my application :
Choose either 1 or 2
if 1, show only A table
if 2, show only B table
Is that possible please ?
Thank you
Use of ROLES is one way:
CREATE ROLE roleA;
CREATE ROLE roleB;
GRANT SELECT ON tableA to roleA;
GRANT SELECT ON tableB to roleB;
GRANT roleA to TheUser;
GRANT roleB to TheUser;
When the user chooses a role in your application, issue the appropriate SET ROLE command:
User chooses 1:
SET ROLE roleA;
Otherwise,
SET ROLE roleB;
Since the roles are not defaults, they will only be active via the SET ROLE command. You can password protect the roles, too.