| Subject | Re: [firebird-support] Users and Roles |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-10-10T22:12:59Z |
At 05:32 AM 11/10/2007, you wrote:
ROLE and GRANT in the IB 6 beta docs LangRef.pdf if you don't own any
more recent literature on Firebird.
use roles to assign privileges...that's the whole idea.
either (although they don't work like Firebird's or like standard SQL).
1. You create a role.
2. You grant a package of privileges to the role.
3. Then you grant the role ("the package") to the user.
You might have more than one role defined, e.g. ROLE_A has privileges
for A, B, C and D, while ROLE_B has privileges for W, X, Y and Z.
You can grant both ROLE_A and ROLE_B to user NICOLAS, for
example. Then, when NICOLAS logs in, he uses ROLE_A for accessing a
DB via certain applications, while he uses ROLE_B for accessing others.
In other words, ROLE is not for grouping users, it is for packaging privileges.
You should also be aware that users are defined at server level, not
at database level. (so this is different to what you're used to in
MSSQLSvr as well). At login, the user and password are authenticated
at the server gateway before attempting to connect to any user
database. After that, the password becomes irrelevant but the user
name remains relevant to SQL privileges once the user is
connected. You can have user names in your SQL privileges that don't
exist in the security database.
./heLen
>Hi all, I been using firebird for less than a month and I'm really happyThey haven't changed in the Firebird era. See the doc for CREATE
>with it. I can't find documentation on Roles.
ROLE and GRANT in the IB 6 beta docs LangRef.pdf if you don't own any
more recent literature on Firebird.
>I've created a role andThat's correct. You have to supply both user name and role if you
>assigned it to a user but it only works if I connect the user an explicitly
>use the role name.
use roles to assign privileges...that's the whole idea.
>Let me put it like this:No. And really MS SQL Server's sql privileges don't work like that
>
>1) I connect the user to the firebird database as user/password. It doesn't
>have the permission assigned to the role "role1" (for example).
>2) If I connect the same user to the database as user/password/role it does
>have the permissions granted to the role "role1".
>
>Can I just connect the user as user/password and automatically get the
>permissions to all the roles assigned to the user as it is in MS SQL Server
>for example?
either (although they don't work like Firebird's or like standard SQL).
>If I have a user with two roles, do I have to create a "meta-role" andUsers don't "have" roles.
>assing both roles to it, and then grant this meta-role to the user?
1. You create a role.
2. You grant a package of privileges to the role.
3. Then you grant the role ("the package") to the user.
You might have more than one role defined, e.g. ROLE_A has privileges
for A, B, C and D, while ROLE_B has privileges for W, X, Y and Z.
You can grant both ROLE_A and ROLE_B to user NICOLAS, for
example. Then, when NICOLAS logs in, he uses ROLE_A for accessing a
DB via certain applications, while he uses ROLE_B for accessing others.
In other words, ROLE is not for grouping users, it is for packaging privileges.
You should also be aware that users are defined at server level, not
at database level. (so this is different to what you're used to in
MSSQLSvr as well). At login, the user and password are authenticated
at the server gateway before attempting to connect to any user
database. After that, the password becomes irrelevant but the user
name remains relevant to SQL privileges once the user is
connected. You can have user names in your SQL privileges that don't
exist in the security database.
./heLen