> > > Has anyone tried the AlterUser function against FB2?
> > > I seem to have struck an issue with the GroupName field.
> > > The services API doesn't like talking about GroupName
> > > anymore, but it does
> > > respond to groupID.
> > > Maybe AlterUser needs to be modified to accommodate this for FB2?
> >
> >Will someone confirm with me if this was a problem with Firebird
> 2.0 that is
> >now fixed in its later release?
>
> No. But I think it possibly highlights some of the ramifications of
> the security changes in Fb 2.0.
>
> The prime thing is that now, you can only access the authentication
> database via the Services API. AFAIK, IBO's AlterUser, etc., use the
> old database API functions, so you now need to use the Admin
> components. However, there are problems there, too, since Lorenzo's
> IBOAdmin components haven't been updated for years.

these components work fine with FB2 - I have tested all the functions

>
> There is a new security database in Fb 2.0, security2.fdb. One needs
> to run a script to convert an old security.fdb to security.fdb. This
> is described in much detail in the Security chapter of the release
> notes. There is a script in the Appendix.
>
> Nothing in userland now touches the security database itself. The
> old USERS table has gone, replaced by RDB$USERS. The API now
> accesses a view named USERS. Public has only UPDATE access to the
> old USERS fields (not INSERT or DELETE) meaning a user can change his
> own credentials but not add or delete users. An old bug in
> impersonation (see below) meant that, with the firebird client DLL
> 1.5.2 and below, and all Interbase client DLL versions, ordinary
> users could access the live security database provided they supplied
> the SYSDBA username and password.
>
> I don't know what the exact problem is with GroupName specifically,
> since it is updatable in the view and SHOULD be accessible via the
> Services API. Are you sure that you are accessing the security DB
> via the Services API, i.e. using the IBOAdmin TIBOSecurityService
> component. However, GroupID and GroupName apply only to POSIX
> servers and their usage is to make it possible to define Firebird or
> InterBase users using the Unix group membership
> credentials. Previously it was simply a no-op on Windows; possibly
> there is some platform-specific disabling mechanism now for
> Windows-based service, although I haven't of it...HOWEVER...
>
> It's conceivably related to another notable change in Fb 2.0. User
> Impersonation has been disabled completely. It has been broken in
> Windows since IB 5.x or even before...it's a security
> vulnerability....and it has had a history of causing
> problems/vulnerabilities for IBO, anyway, at least as far back as Fb
> 1.5.2. A short-term fix was done in the Fb 1.5.3 client to remove
> the vulnerability. Now, nothing, not the root user on POSIX nor
> Administrator on Windows can impersonate the SYSDBA.
>
> So, in short, if the whole security accessibility aspect of the two
> APIs hasn't been closely examined for Firebird 2.0 compatibility, it
> needs to be.
>
> Helen

agreed.
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.
Alan