Subject | RE: [ib-support] RDB$USER_PRIVILEGES Question |
---|---|
Author | Helen Borrie |
Post date | 2003-04-04T07:52:20Z |
At 02:51 PM 4/04/2003 +1000, you wrote:
Also, do you realise that ALL is a different privilege from the individual
DELETE, INSERT, UPDATE and REFERENCES privileges? REVOKE ALL will only
revoke privileges that were granted with GRANT ALL. And revoking rights to
PUBLIC will not revoke rights that were explicitly granted to <username>.
Regarding the deletion of users from the security database not triggering
the deletion of privileges granted to those users within each individual
database, it figures. The security db is just a database, after all. I
can't think of a practicable way that an automatic multi-database "chain
reaction" to deleting a user could be set off, unless the SYSDBA had
simultaneous exclusive access to all DBs on the server inside the same
transaction.
Privileges left orphanned in databases by deleting users won't "eat"
anything except disk space. If a user can't log in, then it's irrelevant
that privileges remain for it. But it's desirable that the appointed
SYSDBA person be reasonably in control of the user base, typically by
maintaining grant and revoke scripts that can be drawn on when needed, to
clean out departing users' rights before deleting the users.
heLen
>OK Sorry - slightly wrong syntax on my revoke statementWhat error do you expect?
>funny that the syntax error does not create an exception.. why is this?
>e.g.
>revoke all ON DESKTOPUSER FROM "01CLARKKENT"
>does not raise an error??
Also, do you realise that ALL is a different privilege from the individual
DELETE, INSERT, UPDATE and REFERENCES privileges? REVOKE ALL will only
revoke privileges that were granted with GRANT ALL. And revoking rights to
PUBLIC will not revoke rights that were explicitly granted to <username>.
Regarding the deletion of users from the security database not triggering
the deletion of privileges granted to those users within each individual
database, it figures. The security db is just a database, after all. I
can't think of a practicable way that an automatic multi-database "chain
reaction" to deleting a user could be set off, unless the SYSDBA had
simultaneous exclusive access to all DBs on the server inside the same
transaction.
Privileges left orphanned in databases by deleting users won't "eat"
anything except disk space. If a user can't log in, then it's irrelevant
that privileges remain for it. But it's desirable that the appointed
SYSDBA person be reasonably in control of the user base, typically by
maintaining grant and revoke scripts that can be drawn on when needed, to
clean out departing users' rights before deleting the users.
heLen