After peeking the source, a few possible areas of improvement:
- You can use `fstat` and keep a file handle around, likely further improving performance (well, reducing the performance hit to other users of the filesystem by not resolving vfs nodes). If you do this, you'll have to check for file deletions.
- If you do stick with stat(2), it might be a good idea to track the inode number from the stat result in addition to the time,size tuple. That handles the "t,s = 1,2; honker gets SIGSTOPped/CRIU'd; database file replaced; honker started again", as well as renameat/symlink-swap fiddling. Changing inode probably should just trigger a crash.
- Also check the device number from the stat call. It sounds fringe, but the number of weird hellbugs I've dealt with in my career caused by code continually interacting with a file at the same time as something else mounted an equivalent path "over" the directory the file was originally in is nonzero.
- It's been a few years since I fought with this, but aren't there edge cases here if the system clock goes backwards? IIRC the inode timestamp isn't monotonic--right? There are various strategies for detecting clock adjustment, of various reliability, that you could use here, if so. Just checking if the mtime-vs-system-clock diff is negative is a start.
That covers the more common of the "vanishingly uncommon but I've still seen 'em" cases related to file modification detection. Whether you choose to cope with people messing with the file via utime(2) is up to you (past a point, it feels like coping with malicious misuse rather than edge cases). But since your code runs in a loop, you're well-positioned to do that (and detect drift/manipulations of the system clock): track a monotonic clock and use it to approximate the elapsed wall time between honker poller ticks (say it fast with an accent, and you get https://www.bbc.com/news/world-latin-america-11465127); if the timestamp reported by (f)stat(2) ever doesn't advance at the same rate, fall back to checksumming the file, or crashing or something. But this is well into the realm of abject paranoia by now.
It's been a decade or so since I worked in this area, so some of that knowledge is likely stale; you probably know a lot more than I do after developing this library even before considering how out-of-date my knowledge might be. When I worked on this stuff, I remember that statx(2) was going to solve all the problems any day now, and then didn't. More relevant, I also remember that the lsyncd (https://github.com/lsyncd/lsyncd) and watchman (https://github.com/facebook/watchman) codebases were really good sources of "what didn't I think of" information in this area.
But seriously, again, nice work! Those are nitpicks; this is awesome as-is!
I actually looked at fstat, but the "check for deletions" piece, given I'm polling at 1kHZ, was the reason I decided not to use it. Older hardware actually made this a big issue but it's fast enough now I decided it wasn't a problem.
I'll ignore the malicious ones bc [out of scope declaration]. Object paranoia is an artifact of build trama and I respect that lmao.
I've just looked into the device number and system clock issues. I think what i'll end up doing is actually a combo of ncruces's above comment and your feedback: a 1kHZ data_version and a 10HZ stat() with version check. This gets around syscall load, avoid clock issues, avoids the WAL truncation issues that others have mentioned, and is both lighter weight and less bugabooable than my previous design.
There's more process-based concurrency than you'd expect in shops that use those languages.
Cron jobs might need to coordinate with webservers. Even heavily threaded webservers might have some subprocesses/forking to manage connection pools and hot reloads and whatnot. Suid programs are process-separated from non-suid programs. Plenty of places are in the "permanent middle" of a migration from e.g. Java 7 to Java 11 and migrate by splitting traffic to multiple copies of the same app running on different versions of the runtime.
If you're heavily using SQLite for your DB already, you probably are reluctant to replace those situations with multiple servers coordinating around a central DB.
Nit:
> languages that only have process based concurrency python/JS/TS/ruby
Not true. There are tons and tons of threaded Python web frameworks/server harnesses, and there were even before GIL-removal efforts started. Just because gunicorn/multiprocessing are popular doesn't mean there aren't loads of huge deployments running threads (and not suffering for it much, because most web stacks are IO bound). Ruby's similar, though threads are less heavily-used than in Python. JS/TS as well: https://nodejs.org/api/worker_threads.html
That's a low-leverage place to intervene. Whether or not the internal admin system was directly OAuth linked to Google, by the time the attacker was trying that, they already had a ton of sensitive/valuable info from the employee's Google Workspace account.
If you can only fix one thing (ideally you'd do both, but working in infosec has taught me that you can usually do one thing at most before the breach urgency political capital evaporates), fix the Google token scope/expiry, or fix the environment variable storage system.
I'm not sure that's necessarily a "problem", though it is fundamental to secrets. We wouldn't say that it's a fundamental problem that doors on houses need a key--that's what the key is for--the problem is if the key isn't kept secure from unauthorized actors.
Like, sure, you can go HAM here and use network proxy services to do secret decryption, and only talk from the app to those proxies via short-lived tokens; that's arguably a qualitative shift from app-uses-secret-directly, and it has some real benefits (and costs, namely significant complexity/fragility).
Instead, my favored option is to scope secret use to network locations. If, for example, a given NPM token can only be used for API calls issued from the public IP endpoint of the user's infrastructure, that's a significant added layer of security. People don't agree on whether or not this counts as a "token ACL", but it's certainly ACL-like in its functionality--just controlled by location, rather than identity.
This approach can also be adopted gradually and with less added fragility than the proxy-all-the-things approach: token holders can initially allowlist broad or shared network location ranges, and narrow allowed access sources over time as their networks are improved.
Of course, that's a fantasy. API providers would have to support network-scoped API access credentials, and almost none of them do.
Speaking of fantansies...another approach would be holder binding: DPoP (RFC 9449) has been stable for a couple of years, AWS SigV4 does it too. The key holder proves control at call time, so a captured token without the key is useless.
> other things (alcohol) that cause problems and are not being restricted
Alcohol is heavily restricted, though. You can't sell it to minors, younger minors can't drink it in public, you can't sell/buy/make it above a certain proof, you can only resell it from authorized distributors, it is taxes, and so on.
Sure, banning cigarettes for a specific generation is a much more stringent restriction, but plenty of other restrictions exist.
Sounds like a great way to avoid alcohol addiction, prevent drunk driving deaths, and save countless generations from being negatively impacted in one way or another by alcohol.
Prohibition doesn't work because people want to modulate their consciousness, chemically force-relax, reduce inhibitions, etc. It didn't work before, and it won't in the future. The more things are forbidden, the more taboo and attractive they become.
This banal, smiling, petty authoritarianism sickens me. Bodily autonomy trumps "common good" arguments, and where it somehow doesn't, injustice abides. Society's job isn't to crush individualism in order to create the safest and most financially efficient outcome. Shall we throw everyone in prison for their safety and protection next, and control their diet to ensure maximum healthspan and potential for participation in the labor market?
Rather than banning anything, point out at an early age that cigarettes stink, get you addicted, cost money forever, and cause health problems. Point out that alcohol makes you fat and causes heart problems and cancer. The accept that each person has the right to make a decision for themselves about what risks they're willing to accept to achieve a desired outcome, and that they have to own those consequences.
Don't want to pay for smokers' lung cancer treatment? Then only fund palliative care for smoking-related cancers. Man enough to smoke a pack a day, man enough to buy smokers' insurance. There, now we can live free.
Smokers already more than pay for their healthcare so punishing them further is silly. Not only is their lifetimehealthcare cheaper, because smoking disqualifies you from many procedures and kills most users right around retirement age before the expensive age-related care becomes common, but the sin-tax collected from smokers in most countries is larger than the average lifetime medical care cost.
It's basically taxing people for saving everybody else money.
An interesting point. So over the next ~60 years, the UK has committed itself to having to find a replacement for all the tax revenue that will be lost by eliminating tobacco products. Additionally, the number of people with longer lifespans will increase, necessitating more late-life care delivery through the NHS, which will also have to be funded.
Outcome: this will cost everyone a lot of money. Time to raise the retirement age to 80!
In huge agreement with you. But can it be done in a different way that doesn't create the black market problems of the prohibition era? (Do we have a better chance now with gen z's aversion to drugs/alcohol?)
It’s awesome to decide what your children, once they are adults, can’t do? Seems borderline psychopathic. Kinda sums up democracy in current times though.
> It’s awesome to decide what your children, once they are adults, can’t do?
You do realize that this is what basically every single law in existence does, right?
That my kids, and likely yours, once they're adults, can't drive under the influence, rob a bank, impersonate a cop, lie under oath, exercise medecine without a licence, walk downtown naked, jaywalk, evade taxes, criticize the King?
I've seen confusion about this before with people that I know.
You tell them it's against the law to drink, and they'll point out that it's restrictive and controlling. You tell them it's against the law to commit tax fraud, and they'll have no objection.
Why? I think, at least with the people that I know, it's related to what they want to be able to do. They want to be able to drink alcohol, so it feels controlling to tell them they can't. They aren't interested in committing tax fraud, so they're not bothered by that being restricted.
If you check it the other way around, you'll get consistency. Almost everyone that is against taxation is also against restrictions on consuming drink.
If you ask an addict then yeah you'll get some gibberish that enables them whether it fits into a logical paradigm or not.
Well to be fair, it's not that they can't, it's that society is telling them there will be repercussions if they're caught. You can still technically do whatever you want.
Laws are threats made by the dominant socioeconomic-ethnic group in a given nation. It’s just the promise of violence that’s enacted and the police are basically an occupying army.
People have been using tobacco for many thousands of years. if they want to use it knowing full well the consequences, they should be able to. Unless we also ban things like skydiving, rock climbing, and fast cars and motorcycles, it makes no sense to me.
Why isn't prohibiting something known to cause harm a good thing? Plus, smoking doesn't just harm the individual doing it, its harm extends to those in the immediate (and sometimes not so immediate) vicinity, as well as the environment. There is literally zero good to gain from it.
If future generations want to smoke, they can change the law as easily as yours passed it.
Running government budgets further and further into deficit, believing that, as a result, your children will, some day, be in a stronger financial position to repay the resulting debt that, until that day, continues to grow at an ever-increasing rate?
That's not how politics works, and you probably know it. "Easily passing laws" is not a matter of voting demographics but of political power, and any thinking person knows political power usually does not belong to younger voters.
I’m having a hard time coming up with a better way. Simply banning all manufacturing and import is not going to work when it’s heavily addictive. In the case of alcohol, quitting cold can kill you.
Banning it today and expecting people to cope, or attempt to fund recovery efforts for a whole nation would completely misunderstand the addicts mind. If you don’t want to quit, you never will.
Instead we have a total ban that is timeboxed to allow the addicts the rest of their lives to quit one way or another.
This is a great idea. To slightly sidetrack things: I think updating computer UI text selection behavior to not break click/snap-to-next selectable words on colons without padding spaces in general would be a good thing.
"A: B" would still click-select either "A:" or "B", but "1:2" (a ratio) would select the whole thing, as would "small:med:large" or an ipv6 address. In other words, I think that, in practice, English writing has assigned semantic significance to space-less colons in enough cases that text selection systems should reflect that.
Though I'm not sure RFCs are going to drive general GUI behavior--they won't "MUST" it, because that's overstepping, and I'm not sure GUI/OS-text-selection-functionality maintainers will be persuaded otherwise.
ZFS snapshots can be transmitted over the network, with some diff-only and deduplication gains if the remote destination has an older instance of the same ZFS filesystem. It’s not perfect, and the worst case is still a full copy, but the tooling and efficiency wins for the ordinary case are battle-tested and capable.
Yes, for sure, and stuff like this is really useful when rebalancing storage nodes, for example.
My point is that for the use case of offering a Postgres service with CoW branching as a key feature, you can't really escape some form of separation of storage and compute.
Btw, don't really want to talk too much about it yet, but our proprietary storage engine (Xatastor) is basically ZFS exposed over NVMe-OF. We'll announce it in a couple of weeks, and we'll have a detailed technical blog post then on pros/cons.
After peeking the source, a few possible areas of improvement:
- You can use `fstat` and keep a file handle around, likely further improving performance (well, reducing the performance hit to other users of the filesystem by not resolving vfs nodes). If you do this, you'll have to check for file deletions.
- If you do stick with stat(2), it might be a good idea to track the inode number from the stat result in addition to the time,size tuple. That handles the "t,s = 1,2; honker gets SIGSTOPped/CRIU'd; database file replaced; honker started again", as well as renameat/symlink-swap fiddling. Changing inode probably should just trigger a crash.
- Also check the device number from the stat call. It sounds fringe, but the number of weird hellbugs I've dealt with in my career caused by code continually interacting with a file at the same time as something else mounted an equivalent path "over" the directory the file was originally in is nonzero.
- It's been a few years since I fought with this, but aren't there edge cases here if the system clock goes backwards? IIRC the inode timestamp isn't monotonic--right? There are various strategies for detecting clock adjustment, of various reliability, that you could use here, if so. Just checking if the mtime-vs-system-clock diff is negative is a start.
That covers the more common of the "vanishingly uncommon but I've still seen 'em" cases related to file modification detection. Whether you choose to cope with people messing with the file via utime(2) is up to you (past a point, it feels like coping with malicious misuse rather than edge cases). But since your code runs in a loop, you're well-positioned to do that (and detect drift/manipulations of the system clock): track a monotonic clock and use it to approximate the elapsed wall time between honker poller ticks (say it fast with an accent, and you get https://www.bbc.com/news/world-latin-america-11465127); if the timestamp reported by (f)stat(2) ever doesn't advance at the same rate, fall back to checksumming the file, or crashing or something. But this is well into the realm of abject paranoia by now.
It's been a decade or so since I worked in this area, so some of that knowledge is likely stale; you probably know a lot more than I do after developing this library even before considering how out-of-date my knowledge might be. When I worked on this stuff, I remember that statx(2) was going to solve all the problems any day now, and then didn't. More relevant, I also remember that the lsyncd (https://github.com/lsyncd/lsyncd) and watchman (https://github.com/facebook/watchman) codebases were really good sources of "what didn't I think of" information in this area.
But seriously, again, nice work! Those are nitpicks; this is awesome as-is!
reply