Subject | Re: [firebird-support] invisible user/password environment variables |
---|---|
Author | Helen Borrie |
Post date | 2004-02-05T07:05:44Z |
At 07:38 AM 5/02/2004 +0100, you wrote:
care who you are, as long as you exist in security.fdb. Any user who
exists can log in to any database. Once you are logged in, of course you
can't access anything unless your username has permissions to objects therein.
In embedded, that user verification is bypassed - hence, you can use any
old user name and password, even non-existent, and get connected to the
database. But you still won't have access to see or do anything in the
database unless the DATABASE has permissions for your user name (or a ROLE
that your user name has permissions for) for the objects you try to access.
Of course, if you log in as SYSDBA, you have full privileges to everything,
including "DROP DATABASE" and there is currently no way to revoke SYSDBA
permissions. That's why it is ultra-dumb to write any END-USER app that
connects everyone as SYSDBA.
/hb
> > I am using Firebird 1.5 -- the embedded server. I am able to queryWell, almost. In the *normal* server situation, the security check doesn't
> > against the employee.fdb database using isql, so I know that much is
> > working.
> > (Parenthetically, it seems I can connect with any user/password
> > combination, even non-existent ones. Can someone explain that behavior
> > to me?)
>
>Embedded doesn't use User and Password at all, "security" is achieved by
>means of the OS, whoever
>can log into the computer can use the DB through your application.
care who you are, as long as you exist in security.fdb. Any user who
exists can log in to any database. Once you are logged in, of course you
can't access anything unless your username has permissions to objects therein.
In embedded, that user verification is bypassed - hence, you can use any
old user name and password, even non-existent, and get connected to the
database. But you still won't have access to see or do anything in the
database unless the DATABASE has permissions for your user name (or a ROLE
that your user name has permissions for) for the objects you try to access.
Of course, if you log in as SYSDBA, you have full privileges to everything,
including "DROP DATABASE" and there is currently no way to revoke SYSDBA
permissions. That's why it is ultra-dumb to write any END-USER app that
connects everyone as SYSDBA.
/hb