Earlier quoted context omitted.
It seems like standard operating procedure for web apps has been to immediately throw out the user account system of whatever data store is being used and use one account with full CRUD access (or worse), with a (mediocre to disastrous) home-grown permissions system shoehorned into the controller layer. That may be because of programmer laziness or because of some sort of inherent impedance mismatch between web-scale…
Show me a 'web-scale' system that has a single data-store to secure in the first place. Something like much-better-Oracle-row-based-auth or whatever isn't gonna cut it.. cause who watches over Redis, or memcache, or the filesystem?
I realize that there are huge scaling/throttling/DoS issues with, say, creating a new UNIX user every time someone signs up for your online meme generator, but that's mostly because UNIX wasn't really designed for millions of users on one box.
On the other hand, as an unprivileged user on a Linux box, you can't really do much damage beyond hogging resources and possibly spying on other people's poorly-secured files. If there's a bug and you do find a way to trash the system or escalate privilege, it's front-page news.
The problem right now is that every two-bit web app implements its own ad-hoc permissions system, often at the wrong layer of their stack. If it could be commoditized into a widely-used and widely-audited system, I think it would do a lot to improve security on the Internet.
(To open up a whole new unsupported argument, on some level the fact that one needs a key-value store, a filesystem, and a hand-optimized in-memory cache to build a reasonably fast web service smells like we're still making humans do a lot of things that a machine could do a much better job of.)