SQLite Forum

Timeline
Login

6 forum posts by user HiddenWindshield

2021-06-29
19:55 Reply: Opening a DB with SQLITE_OPEN_EXCLUSIVE (artifact: 528a918224 user: HiddenWindshield)

Thanks for pointing this out! Also, thanks to the SQLite developers!

2021-06-24
16:13 Reply: Opening a DB with SQLITE_OPEN_EXCLUSIVE (artifact: 1ed4a93725 user: HiddenWindshield)

Originally, POSIX didn't specify the O_EXCL flag, using much the same reasoning you're using now. After all, what harm could come from some other process creating a file in between checking if it already exists and actually performing the open?

Then, someone (and I can't find the link to the story right now, sorry) demonstrated that this race condition opened up a security hole. They could trick a legitimate program into overwriting a sensitive file that the attacker wouldn't normally have access to. After a lot of back-and-forth, the Gods of POSIX eventually relented and added the O_EXCL flag to the open(2) function.

Now, I get that the odds of this actually opening an exploitable security hole are remote. But they aren't zero. And if you pay attention to computer security news, you'll see that "remote chance of a security hole" exploits crop up all the time. It's enough to make any developer (such as myself) just a little bit paranoid about my code.

But, the thing is, there are absolutely no downsides to allowing exclusive open whatsoever. So, no matter how small the improvement may or may not be, if it is an improvement with no drawbacks, why wouldn't you implement it?

2021-05-13
14:22 Reply: Opening a DB with SQLITE_OPEN_EXCLUSIVE (artifact: 3c63d59d85 user: HiddenWindshield)

I appreciate the tip, but I already have a much better (if slightly more cumbersome) workaround as I linked above.

But my point is I shouldn't need a workaround at all. Filtering out the "exclusive" flag* provides exactly zero benefit, while at the same time preventing the standard solution to the aforementioned race condition.

Which is why I would still like to politely request of the developers that this completely useless and counterproductive filter be removed from the production version of SQLite. Thank you.

*Putting "exclusive" in quotes to emphasize again that the flag in question doesn't actually open the file in any kind of "exclusive" mode and is badly named.

2021-05-07
14:44 Edit reply: Opening a DB with SQLITE_OPEN_EXCLUSIVE (artifact: 1a5da9296c user: HiddenWindshield)

"Failing if the file already exists" is exactly the behavior I want. I don't want "exclusive access". Would it help if they renamed it "SQLITE_FAIL_IF_EXISTS"? I mean, I know they named it after the POSIX "O_EXCL" flag, but I always thought that flag was weirdly named to begin with.

I appreciate the workaround, but I'm developing on Linux for a program that's eventually going to be multi-platform, so a Windows-only solution wouldn't work for me.

I did find a better workaround (from back in 2017, so this bug has obviously been around for a while), but that involves modifying the VFS, and you have to maintain a separate state variable to change whether you want exclusive mode or not. It would be so much simpler if the developers would just stop filtering that particular flag out of the flags parameter.

14:30 Reply: Opening a DB with SQLITE_OPEN_EXCLUSIVE (artifact: 961cc36b2b user: HiddenWindshield)

"Failing if the file already exists" is exactly the behavior I want. I don't want "exclusive access". Would it help if they renamed it "SQLITE_FAIL_IF_EXISTS"?

I appreciate the workaround, but I'm developing on Linux for a program that's eventually going to be multi-platform, so a Windows-only solution wouldn't work for me.

I did find a better workaround (from back in 2017, so this bug has obviously been around for a while), but that involves modifying the VFS, and you have to maintain a separate state variable to change whether you want exclusive mode or not. It would be so much simpler if the developers would just stop filtering that particular flag out of the flags parameter.

2021-05-04
14:12 Post: Opening a DB with SQLITE_OPEN_EXCLUSIVE (artifact: 680cd395b4 user: HiddenWindshield)

I would like to submit a bug report, and was told that the SQLite team prefer that they be submitted through the forum to keep the noise down on the actual bug tracker. So, here goes:

When trying to create a new database, the sqlite3_open_v2() function silently filters out the SQLITE_OPEN_EXCLUSIVE flag. I've looked at the source code, read the documentation, and everything I can find says that that's the intended behavior. But doing it this way creates a race condition. That is, after all, why POSIX added the O_EXCL flag to the open() call.

Now, I realize that the odds of this actually being exploited are very, very slim. But that's not zero. So I'd like to request that SQLite properly handle the SQLITE_OPEN_EXCLUSIVE flag properly rather than just silently filtering it out. Thank you.