Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Firebird User" on OSX considered harmful [CORE3871] #4209

Open
firebird-automations opened this issue Jun 18, 2012 · 5 comments
Open

"Firebird User" on OSX considered harmful [CORE3871] #4209

firebird-automations opened this issue Jun 18, 2012 · 5 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Maury Markowitz (maury.markowitz_gmail.com)

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @paulbeach

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Maury Markowitz (maury.markowitz_gmail.com)

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"?

@firebird-automations
Copy link
Collaborator Author

Commented by: @paulbeach

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Maury Markowitz (maury.markowitz_gmail.com)

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @paulbeach

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant