> At 12:39 PM 16/11/2006, Alan McDonald wrote:
>
> >another point: most grant management tools have been effected by the new
> >standard security view. If you manage your database, logged on as the
> >creator or the database, you are no longer able to grant roles to users
> >because they are not visible (the users). You meed to patch the view to
> >provide for this functionality by adding your db creator user name to the
> >view as in
> >SELECT RDB$USER_NAME, RDB$SYS_USER_NAME, RDB$GROUP_NAME,
> RDB$UID, RDB$GID,
> >RDB$PASSWD,
> >RDB$PRIVILEGE, RDB$COMMENT, RDB$FIRST_NAME, RDB$MIDDLE_NAME,
> >RDB$LAST_NAME,
> >RDB$first_name || _UNICODE_FSS ' ' || RDB$middle_name || _UNICODE_FSS ' '
> >|| RDB$last_name
> >FROM RDB$USERS
> >WHERE CURRENT_USER = 'SYSDBA'
> >OR CURRENT_USER = RDB$USERS.RDB$USER_NAME
> >OR CURRENT_USER = 'mycreatoruser'
> >
> >It's either this or you go back to creating databases with SYSDBA
> >exclusively.
>
> While it's probably correct that some third-party grant management
> tools need to review their assumptions on the queries they run, it's

no adjustment in the queries will allow for a non-sysdba user to "see" other
usernames for a GUI grant experience (unless you patch the security database
view).
Alan

> still not true that the USERS table (or view, in the Fb2 case) has to
> be "visible" in order to grant permissions in a database. They are
> not connected to each other in any way. You can grant permissions to
> ANY username, whether it exists in the security database or
> not. You'll come unstuck trying to log in with that non-existent
> username, of course.
>
> Helen