i would like to unsubscribe from this mailing list 2010/1/7 KaiGai Kohei <kai...@ak.jp.nec.com>
> (2010/01/07 17:55), Toru Maesaka wrote: > >> Please use the correct term to avoid confusion :( > >> Authentication is a different concept from access control. > > > > Point taken :) > > > >> Obviously, it is valueable. > >> > >> My proposition is just a framework to host an additional access control > >> feature without any assumption for security models. In other word, the > >> default installation does not apply any access controls, unless > >> administrator explicitly set up its own security module. > >> > >> Please note that any security solution has its own assumption, so the > >> preferable answer depending on the situation. > >> In our assumption, it is difficult to keep application bug/vulnerability > >> free, so we need to minimize the number of points to be checked. > >> It is also why operating system checks filesystem permission on the > system > >> call invocations, not application side. > > > > Like I said, I understand your argument. The question is what > > proportion of the users would benefit from this? To be honest I don't > > have the answer for this. However, taking into account that memcached > > has been used worldwide > > without serious complaints by players of all sizes in it's history, I > > don't think it's necessary. Damn, I was even skeptical of the SASL > > support at the beginning (I agree with this now though). I just don't > > want to see memcached get bloated by adding database-like > > functionalities. > > I don't deny it is niche. However, it is absolutely necessary feature > for people who want to set up secure web application platform. > > So, I suggested this idea with modular approach, not built-in. > > > However, I have nothing against people providing this functionality > > inside their engines. In fact, I think it would be fantastic! This was > > my original view of the Engine Project (additional things should be > > provided by the engine) which was fortunately embraced by the > > community. The binary protocol turned out to be useful for this too. > > It seems to me there is no difference from what I said, except for name > of the framework. > > Right now, I'm not clear whether the engine is a reasonable framework > to host access control feature, or not. So, I represented it just a > security framework. > > Anyway, system administrators can decide whether the memcached should > load the access control module on the "engine" framework, or not. > Of course, he can pay mention about its tradeoff. > > >> BTW, Is the storage engine stackable? If not so, it seems to me we will > >> face a tradeoff between persistent storage and access controls. > > > > No. It's not stackable. If you want to do this you'd have to create an > > abstraction layer within the storage engine. There were discussions on > > this a while back though (I forget if it was online or offline). > > It seems to me it is a bit ad-hoc workaround. > For example, when the primary module allocate an item object, what should > the secondary module perform? > > However, it is not a bad idea to start it from the upcoming engine > framework. > > Thanks, > > > Cheers, > > Toru > > > > > > 2010/1/7 KaiGai Kohei<kai...@ak.jp.nec.com>: > >> (2010/01/07 16:17), Toru Maesaka 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. > >> > >> Please use the correct term to avoid confusion :( > >> Authentication is a different concept from access control. > >> > >>> 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? > >> > >> Obviously, it is valueable. > >> > >> My proposition is just a framework to host an additional access control > >> feature without any assumption for security models. In other word, the > >> default installation does not apply any access controls, unless > >> administrator explicitly set up its own security module. > >> > >> Please note that any security solution has its own assumption, so the > >> preferable answer depending on the situation. > >> In our assumption, it is difficult to keep application bug/vulnerability > >> free, so we need to minimize the number of points to be checked. > >> It is also why operating system checks filesystem permission on the > system > >> call invocations, not application side. > >> > >> If we can trust applications, it is not a wrong approach to control > >> all the things in the application, not memcached. > >> > >>>> 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. > >> > >>> 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. > >> > >> Are you suggesting that applications has to handle the scramble buffer > >> correctly for each accesses? It seems to me we can obtain credential of > >> the client using SASL authentication, without any additional hints. > >> > >> If the security map means something like access control list, what we > >> are talking about is not fundamentally different. > >> The issue is the way to store the properties within the item. > >> > >> BTW, Is the storage engine stackable? If not so, it seems to me we will > >> face a tradeoff between persistent storage and access controls. > >> > >> Am I missing something? > >> > >> Thanks, > >> > >>> Cheers, > >>> Toru > >>> > >>> 2010/1/7 KaiGai Kohei<kai...@ak.jp.nec.com>: > >>>> (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<kai...@ak.jp.nec.com> > >>>> > >>> > >>> > >>> > >> > >> > >> -- > >> OSS Platform Development Division, NEC > >> KaiGai Kohei<kai...@ak.jp.nec.com> > >> > > > > > > > > > -- > OSS Platform Development Division, NEC > KaiGai Kohei <kai...@ak.jp.nec.com> > -- Regards Rami Badran
