About yesterday's thought . . . .
Jun. 2nd, 2006 08:37 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stevenehrbarProbably a bad idea. On any multi-user system with security, system-wide indexes of searchable metadata will serve as a security hole (by allowing users to know of the existence of files that they're not permitted to even know exist) or a massive performance hit (as each metadata search result has to be checked against file permissions before display to the user). And the "solution" I can think of -- include security data in the metadata indexes -- is brittle (since you need to keep it in sync) while being a performance drag (since you need to update *all* the indexes every time permissions on a file or its directory change).
Instead, implement a indesing system that can be turned on/off for each user, and "crawls" the metadata for the file available to the user. Have the B+tree indexes it makes limited to the user alone (ACLed to the user account only if ACLs are in place). It will cause a lower performance hit than the BoOS implementation (you can schedule it as a low-priority task at the expense of being a little bit out-of-date) *and* avoid the security problems of a system-wide index.
(This has all probably been figured out by somebody else at some other time. But I'm an amateur, and am quite proud of myself, thankyouverymuch.)
Instead, implement a indesing system that can be turned on/off for each user, and "crawls" the metadata for the file available to the user. Have the B+tree indexes it makes limited to the user alone (ACLed to the user account only if ACLs are in place). It will cause a lower performance hit than the BoOS implementation (you can schedule it as a low-priority task at the expense of being a little bit out-of-date) *and* avoid the security problems of a system-wide index.
(This has all probably been figured out by somebody else at some other time. But I'm an amateur, and am quite proud of myself, thankyouverymuch.)
