| |||||||||||||
Ghosts of Unix past, part 3: Unfixable designsGhosts of Unix past, part 3: Unfixable designsPosted Nov 16, 2010 20:05 UTC (Tue) by dlang (✭ supporter ✭, #313)Parent article: Ghosts of Unix past, part 3: Unfixable designs
.htaccess is a convienient way to think about permissions, but in terms of performance it's a disaster.
every time apache has to access a file it needs to look in .htaccess for that directory, AND EVERY PARENT DIRECTORY.
As a result, just about every production apache server disables .htaccess files.
(Log in to post comments)
Ghosts of Unix past, part 3: Unfixable designs Posted Nov 16, 2010 20:47 UTC (Tue) by alvieboy (subscriber, #51617) [Link]
That could be solved by simply caching access data in memory. dnotify() also allows you to do proper reloading of ACLs, without having to stat() every file on hierarchy.
But Apache is not only meant for Linux. Other OSes do not provide these functionalities.
What's really harder is to apply all constraints in a fast and efficient way. I never benchmarked Apache on this, but I'd bet its not that fast nor efficient.
Alvaro
Ghosts of Unix past, part 3: Unfixable designs Posted Nov 16, 2010 21:21 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
under the covers, .htaccess files are not just access control files, they can contain any config options that can be in an apache config file, they just apply to that directory and it's subdirectories, discovered per-hit.
so yes, they are horribly inefficient
in terms of caching the combined contraints, that seems hard in the face of directories being moved around.
there's also the issue of the interaction with links and finguring out the 'true' path to a file.
Ghosts of Unix past, part 3: Unfixable designs Posted Nov 17, 2010 1:55 UTC (Wed) by buck (subscriber, #55985) [Link]
maybe i'm a moron, but i find that trying to map the non-hierarchical
layout of the apache httpd.conf to a mental overlay for the server's (virtual) filesystem/URI space to be way beyond my competence. .htac- cess files at least have the virtue of controls being in proximity to the stuff they control, though that thinking runs entirely counter to the point being made in the article, the extended-attribute bloat, etc. so maybe i just drank the inode/xattr Kool-Aid to my permanent detriment, but the ``composability'' of the permissions by masking them through the filesystem's links down to the object of concern is something i just totally grok. (i think there must be some connec- tion i should make here about exploiting the grafted-on filesystem trees design to the full being part-and-parcel, but i am obviously not a big-picture type, and i think that case was made for chroot/name- space forking)
i'll concede that maybe AFS directory-only permissions might simplify
Ghosts of Unix past, part 3: Unfixable designs Posted Nov 17, 2010 2:50 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
no disagreement that they are easier to understand, the problem is the performance implications of them.
Ghosts of Unix past, part 3: Unfixable designs Posted Nov 17, 2010 9:53 UTC (Wed) by iq-0 (subscriber, #36655) [Link]
The beautiful thing is that one doesn't have to do this expensive lookup if the main filesystem/kernel used such a scheme. It would work pretty much like the dentry-cache and one could probably even JIT the possible complex patterns or at least byte-code compile them in memory.
Apache doesn't do this for it is hard to get a good cross-platform file-change notification (which doesn't have possible side-effects).
It even has a good chance to be cheaper than the current unix model, since in a practical setup there would only be a few (compiled) rulesets in effect (still hundreds, but a lot less than actual dentries). One could possibly cache a pointer to the list of effective rules to a dentry/inode (depending on how the rules are to be applied, this is semantics, but I suspect you'd want them on the inode level).
But the decoupling of the details from every single inode can probably be done without any real performance impact (and possibly even performance gains). Whether you use hierarchical ACLs or matching rules shouldn't really make a difference and constant tree traversals shouldn't be necessary when done at the VFS level.
|
|||||||||||||