Access controls on a per-key basis is insane for lots of reasons. If you
need separate applications to only be able to access their own keys, set up
a separate memcached instance for each app. Problem solved without incurring
the access control overhead, without introducing access control syntax, and
without enabling apps to break each other by accidentally reserving each
other's keys.


/Henrik Schröder

2010/1/6 KaiGai Kohei <[email protected]>

> (2010/01/06 15:14), Dustin wrote:
> >
> > On Jan 5, 10:06 pm, KaiGai Kohei<[email protected]>  wrote:
> >> Is these any design proposals?
> >> Or, could you introduce me who is working on this efforts?
> >>
> >> I've worked on development of secure web application platform using
> SELinux
> >> for a few years. Nowadays, memcached becomes a significant facility for
> >> various kind of web applications, so we cannot ignore access controls on
> >> the key-value store shared by multiple web applications.
> >>
> >> So, I'm interested in the description on the roadmap, and looking for
> more
> >> detailed information about this project.
> >
> >    I suppose we should update those docs a bit:
> >
> >     http://code.google.com/p/memcached/wiki/SASLHowto
> >
> >    Let me know how that goes.
>
> Thanks for the information.
>
> Hmm, indeed, memcached already provides authentication feature, but it is
> different from what I would like to do.
>
> It seems to me it allows authenticated clients to access all the objects
> stored in this memcached server. However, we cannot control accesses on
> certain objects like filesystem permissions, although SASL support enables
> to identify the client.
> (BTW, access control does not always require authentication. For example,
> we can assume a security model based on the source ip addresses.)
>
> Is there any activity to support access controls, not only authentication?
> Or, is it open for new idea or proposition? :)
>
> Thanks,
> --
> OSS Platform Development Division, NEC
> KaiGai Kohei <[email protected]>
>

Reply via email to