> > > >> Via the Services API or "gsec".
> > > >>
> > > >> Not via SQL.
> > > >>
> > > >> Martijn Tonies
> > > >
> > > >Quoting from release notes: "The SYSDBA remains the keeper of the
> > > >security database but users can now modify their own passwords by way
> > > >of a view over the (new) underlying, protected RDB$USERS table."
> > > >
> > > >Seems to me there is a way to change it via view ...
> real-life example
> > > >would help greatly.
> > >
> > > Then try it. You cannot connect to the security database, it is
> > > prohibited.
> > >
> >
> > what annoys me a little is that DBOwners cannot use GUI tools to grant
> > objects to users, since gui tools rely on DBOwners being logged onto the
> > database and once logged on, other users are not visible (in the GUI
> tools).
> > Only SYSDBA will see a full list of users.. So the only way this is
> possible
> > is to modify security2.fdb so the view reads
> > ...
> > WHERE CURRENT_USER = 'SYSDBA'
> > OR CURRENT_USER = RDB$USERS.RDB$USER_NAME
> > OR CURRENT_USER = 'MYDBOWNER'
> > ... OR (keep adding database owners)...;
> >
> > Then you get the GUI grant manager tools working for the database which
> has
> > been created by MYDBOWNER.
>
> The list of users is probably fetched by using the Services API.

the services API will return users from the view,... so logged in as
MYDBOWNER, the security service will return all users if the mods above are
applied (default distro will only return yourself unless you're SYSDBA). The
mods above a very difficult to apply now that direct access is vorboden...
you have to stop the server, copy the security2.fdb, start server, make
changes, stop server, copy back, start server again...

>
> What do you propose as a solution?
>

without a clear idea of where the security changes are going i.e. how they
are to be implemented, it's difficult to propose a solution.
per database security will no doubt introduce yet another layer of difficult
workarounds for certain tasks but does anyone (including Alex Peshkov) have
an implementation guide to follow on this?
I'm not familiar with DBWorkBench grant manager - how does it wrestle with
this task?
In IBExpert you need to design with a connection to the DB as DBOWNER, but
you need to either have a separate connection as SYSDBA to do the grants, OR
you make the mods above, OR you do it all via ISQL command line grant
statements.

Seems to me that we need a way that SYSDBA can add other SYSDBA type users,
special users who you declare as DBOWNERs i.e. used to created databases, so
these users have exceptional rights or are added to the permissions allowed
over the view.
I know there is constant talk of a need to have more than one SYSDBA and to
bar access to databases from SYSDBA. Hopefully somewhere this is all being
talked about, I've not seen any conversations on devel or architect lists.
Alan