(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<[email protected]>: >> (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<[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]> >>>> >>> >>> >>> >> >> >> -- >> OSS Platform Development Division, NEC >> KaiGai Kohei<[email protected]> >> > > > -- OSS Platform Development Division, NEC KaiGai Kohei <[email protected]>
