Issue Details (XML | Word | Printable)

Key: CORE-3871
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Maury Markowitz
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

"Firebird User" on OSX considered harmful

Created: 18/Jun/12 02:03 PM   Updated: 20/Jul/12 03:14 PM
Component/s: Build Issues / Porting
Affects Version/s: 2.5.1
Fix Version/s: None

Environment: OSX 10.7, 64-bit, Intel


 Description  « Hide
Installing using the Mac installer uses a new userid for all file ownership and permissions that makes the system unusable out of the box.

1) the permissions/ownership on /tmp/firebird are set such that the system is in an unusable state:

Statement failed, SQLSTATE = HY000
Can't access lock files' directory /tmp/firebird

The directory must be deleted by hand in terminal.

2) the permissions/ownership of everything else likewise leaves the system in an unusable state:

Statement failed, SQLSTATE = 28000
no permission for read-write access to database /Library/Frameworks/Firebird.framework/Versions/A/Resources/examples/empbuild/employee.fdb

The user must chown or set permissions for everyone read/write to get even the example DB to work.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Paul Beach added a comment - 18/Jun/12 02:13 PM
Not true. What happened in this case is that your initial access to the database was via a local connection with a user that was not part of the firebird group. As such the ownership of the lock files etc defaulted to this user. In future either connect initially using either localhost or the host name first or make sure that any user who connects to firebird directly is part of the Firebird group.
Ownership of the lock files etc should belong either to the user who created them or to firebird for security reasons.

Maury Markowitz added a comment - 19/Jul/12 07:57 PM - edited
I am not sure about what the comment is saying, but here is the connections string used in this case:

localhost:/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb

Is this not matching "either localhost or the host name first"?

Paul Beach added a comment - 20/Jul/12 08:57 AM
There are essentially two ways to acess a firebird database, via the remote access method using either the host name, IP address or localhost, and you can also access Firebird using the embedded method by just specifying the local database name on disk.
As I pointed out earlier, the only way to generate the ttype of error you are seeing above is to use the embedded access before using remote. Embedded will adopt your user name/group characteristics which cannout be shared by the normal user/group allocated to firebird for remote access. If you used localhost as the first attempt to access a database then all will work. If you want to use embedded then at a later data, add your local user to the firebird group. When I test the install of every build, I use a script to delete all traces of Firebird from my Mac, and this includes deleting the firebird user and group. If there was such a basic install problem, I suspect I or someone else would have noticed it by now.

Maury Markowitz added a comment - 20/Jul/12 02:22 PM
I remain confused. Let me describe exactly the steps I followed that caused this error to occur, and maybe you can point out where the problem came in.

1) I installed FB on my Mac under my (the only) account
2) I ran isql from my account to test that the DB was installed properly
3) I immediately got the error when trying to test ODBC
4) I deleted the /tmp/firebird dir and things started working for ODBC

wait...

a) I svn'ed the latest version of ODBCQueryTool and re-tested a bug in the ODBC side I've been trying to solve.
b) I downloaded and installed the DMG the latest version of the entire ODBCKit package
c) the error re-appeared

I can see how the numbered steps led to the problem, but I don't believe the lettered series should have caused it again. Nothing else changed between these runs, they were literally seconds apart.

Paul Beach added a comment - 20/Jul/12 03:14 PM
Give me a simple reproducable test case or try the support list. At the moment I don't see how this can be a bug.