Ahh, now I'm with you. > I don't deny it is niche. However, it is absolutely necessary feature > for people who want to set up secure web application platform.
> It seems to me there is no difference from what I said, except for name > of the framework. Indeed. Apologies for not realizing this earlier... Good luck on hacking your Access Control engine module :) - Toru P.S. It might save your time if you look at this first: http://github.com/trondn/memcached/blob/engine/doc/engine-interface.xml 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> > -- Toru Maesaka <d...@torum.net>
