After sending the previous email, I realized that the engine solution I mentioned is not that good. It limits access to a certain item to one user. A better approach would be to create a security map that associates scrambled data with items.
Cheers, Toru On Thu, Jan 7, 2010 at 4:17 PM, Toru Maesaka <[email protected]> wrote: > Yo all, > > Looks like I've jumped on this band wagon a little late but allow me > to throw in my thoughts. Firstly, I'm totally against item-level > authentication. > > I see KaiGai Kohei's motivation to want this but in the context of > memcached, this is the applications job. I think it could upset mid to > large scale memcached users if we added this. They're using it because > they love the simplicity and the high throughput of memcached. They > can take care of security themselves. I guess things are different in > a hosting environment but there are different solutions for this which > Dustin has been looking into. > > So the question is, is it worth the effort for the memcached project? > >> One question. Is the storage engine an appropriate layer for access >> controls on item level? > > Yes. This wouldn't be too difficult to pull off with Binary Protocol > + Engine API. You could create a scramle buffer and send that with the > most appropriate binary protocol field (worst case, use the reserve > field). This scramble buffer can be appended into the key of the item > inside your engine. So you could pull this off with keys with the > following structure: > > <key_value><scramble_buffer> (or vice versa). > > Pretty much you're free to do anything in the engine. Memcached is > only a darn efficient network interface and protocol parser in the > context of Engine API. > > Cheers, > Toru > > 2010/1/7 KaiGai Kohei <[email protected]>: >> (2010/01/07 13:02), Matt Ingenthron wrote: >>> dormando wrote: >>>>> Getting down to the item level would be tough to accept due to the >>>>> overhead >>>>> involved, one would think though. There may be some ways of getting >>>>> closer to >>>>> access control though without going down to the item level. >>>> >>>> This seems like it'll be solved by an engine dealio. Mapping a user to an >>>> internal instance of the storage system. Sort of like running multiple >>>> instances, *cough*. Getting super granular access levels for a web cache >>>> (more than a few dozen users) would be insane, but if someone really >>>> wants >>>> to they could implement a storage engine for it. >>> >>> My thoughts exactly. That's what engine is for! >> >> Does the engine mean something pluggable or modular? >> If so, it is similar to what I think. >> >> One question. Is the storage engine an appropriate layer for access >> controls on item level? >> >> It might be possible to provide strict separation between users. >> Is it possible to provide read-only or append-only rules for a certain >> users in the item level granularity? >> >>>> It'd be incredibly inefficient on memory, compared to keeping the number >>>> of users down or even running multiple instances. >>> >>> Only if you were trying to go all the way down to the item level. It's >>> possible to have groups of slabs that are dedicated to one label/auth or >>> something like that, right? >> >> It may be possible. However, if the usage of slabs are not balanced, >> it may remove cached object, although we have unallocated cache in >> the slab owned by other label/auth. right? >> >> Thanks, >> -- >> OSS Platform Development Division, NEC >> KaiGai Kohei <[email protected]> >> > > > > -- > Toru Maesaka <[email protected]> > -- Toru Maesaka <[email protected]>
