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

Lock folder inizialization is not multi-process safe [CORE5784] #6047

Closed
firebird-issue-importer opened this issue Apr 4, 2018 · 9 comments

Comments

@firebird-issue-importer
Copy link

firebird-issue-importer commented Apr 4, 2018

Submitted by: Steffen Heil (firebirdsql.org_partner.sh-solutions.de)

Attachments:
firebird-3.0.3.32900.0-unlock.patch

During start, firebird itself as well as gfix check if the folder /tmp/firebird exists and create them if necessary.
However if two processes try that at the same time, there is a short amount of time during that the folder was created but the permissions were not adjusted yet, then one process will raise an exception.

We had real life issure with that like this:
The firebird service was started by systemd first. (Actually starting fbguard.)
Then our own service was started that first called "gfix -w" to configure forced writes and then started a java application that accesses the database.

In one out of 25 reboots firebird failed because it could not access the folder /tmp/firebird, resulting in a "Securtiy Database Error" that was infact an error in initialization of locks. We tracked it down to createLockDirectory in osutils.cpp.

We now simply fixed that by adding ExecStartPre directives to the systemd service to create and configure said folder in advance.

However I strongly think that firebird code should not create such szenarios in the first place. I will attach a patch that fixes the issue.

What I am more concerned about is that there could be a similar race condition with creating the lock *files*.
However in 16.000 reboots we did not have problems there.

So, could someone please add Information on how lock initialization is suppost to work?
Especially if two non-root users start a firebird command line tool like gfix at the same time...

Commits: eae0235 8d500d0

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 4, 2018

Commented by: Steffen Heil (firebirdsql.org_partner.sh-solutions.de)

This patch creates the lock folder in a safe way.
At no time there is a folder with wrong ownership or permissions.

If the folder already exists the performance is not affected.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 4, 2018

Modified by: Steffen Heil (firebirdsql.org_partner.sh-solutions.de)

Attachment: firebird-3.0.3.32900.0-unlock.patch [ 13233 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 5, 2018

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 10, 2019

Modified by: @AlexPeshkoff

summary: Lock folder inizialization is not "threadsafe" => Lock folder inizialization is not multi-process safe

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 10, 2019

Commented by: @AlexPeshkoff

Committed solution is based on a patch suggested by Steffen but is not using Linux-specific system calls (i.e. posix compatible)

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 10, 2019

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.5 [ 10885 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 5, 2019

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Cannot be tested

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 5, 2019

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Oct 2, 2019

Modified by: @dyemanov

issuetype: New Feature [ 2 ] => Bug [ 1 ]

security: Developers [ 10012 ] =>

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