Subject Re: [firebird-support] linux, firebird embedded and $FIREBIRD_TMP
Author Vlad Khorsun
> Vlad Khorsun wrote:
>> Nobody told that users need administrative privileges to work with FB
>> embedded v2.5.
>
> As I understand, when FIREBIRD_LOCK is removed, the only "solution" for
> multi-user access will be to add user to "firebird" group. One cannot do
> that without administrative privilege.

FIREBIRD_LOCK must not be used in the way to make lock file placement
different for different instances of application's used embedded and Firebird
itself.

> Anyway, I call this "solution" because in such case users will be able
> to step on each others toes. When you have a database file which is
> owned by a user, and a lock owned by that user, and group has no access,
> then only that user has access - and he can run multiple applications on
> the same database simultaneously. It seems to me that removal of
> FIREBIRD_LOCK will be the end of this feature. Is this true?

No.

> However, if both users are members of "firebird" group and group has r/w
> access to database and lock, then users can corrupt the database if they
> both access it at the same time. Is my understanding correct?

No, if you will not change FIREBIRD_LOCK in every process to point to
different folders.

You already can have scenario when both classic server and a few embedded
applications will work with the same database.

>> Such privileges needed only at install time and when
>> new users created.
>
> If you have "embedded" application, why would you need to "install" it.
> You just unpack it to some directory in your $HOME and run it. With

Your application can create appropriate folder and set up its permissions
on first need.

> Firebird 2.0 you don't even need to have "firebird" group on the system.
> That's what I call "embedded" database.

This is not secure.

> Please note that this issue is not so much important to me personally,
> but I believe Firebird can stand a very good chance in embedded area and
> it would be a shame to lose some functionality we already have.

We understand it and did nothing (i hope) to loose any existing functionality.
But security can't be ignored.

Regards,
Vlad