Subject Re: [firebird-support] Permissions
Author Helen Borrie
At 06:48 PM 14/09/2005 -0600, you wrote:
>Is there a document on how permissions work for database access on Linux
>using FirebirdCS 1.5.2?

Yes, there's a piece about it in the Fb 1.5 release notes, in the Linux
installation section, though it doesn't give you an explicit rundown of
what the perms have to be in the case of a Linux direct connection.

>I'm afraid the whole system is baffling to me.

Me too. :-)

> I have a database called a1.fdb and its in /tmp and the permissions
>are 0666 so everyone can read and write it but I can't open it with isql
> export FIREBIRD=/opt/firebird
> isql -u sysdba -p ... /tmp/a1.fdb
>I get the error:
> Statement failed, SQLCODE = -902
> operating system directive open failed
> -Permission denied
>So what does this mean? How are permissions denied to a file with all
>read/write permissions enabled and in the /tmp directory? I tried
>changing the ownership and group of the file to "firebird" and that
>didn't help either. I can open it if I specify localhost: before the
>database name but then I'm using a network connection and not a direct
>one which isn't what I want.

Quite possible it's one or more of Firebird's artefacts that the open
directive is failing on. I haven't got time right now to install a Linux
Classic to test theories, but my guess is that possibly you need to add the
necessary permissions for the group to the security database, the lock
file, message file, log file, et al.

And/or MAYBE the engine is hardwired to refuse access to a database file
located in /tmp, given its network-wide exposure and its purpose as a
general dumping ground for files that will become garbage...dunno...if so,
it's undocumented (AFAIK), even if it makes sense that it would be.

Above all, I *always* have database files in safe locations where I can
control the permissions and keep out invaders. Maybe all you need to do is
put the db file in the user's home directory, apply the right permissions
and you're there.

I'd want to approach this from the direction of "knowns" rather than
"unknowns". I don't have any problem local-connecting to my databases on
Classic with the command-line tools; and I don't (as it happens) write
user apps that local connect on Linux, so there are dragons there that I
just haven't met. But, bearing in mind that it's the server embedded in
the client that has to open all the bits and pieces and give you access to
security.fdb, presumably the OS user that loads needs the
appropriate permissions on those bits and pieces as well...