(2010/01/07 11:07), Aaron Stone wrote: > 2010/1/6 KaiGai Kohei<[email protected]>: >> (2010/01/07 9:14), Matt Ingenthron wrote: >>> Aaron Stone wrote: >>>> On Wed, Jan 6, 2010 at 2:48 AM, pub crawler<[email protected]> >>>> wrote: >>> (snip...) >>>>> Needless to say, permissions and authentication is a feature set that >>>>> is going to re-requested for addition now and in the future. It opens >>>>> the door for someone to create a memcached variation with such a >>>>> feature set - anyone? >>>> >>>> Please don't. Please nobody even think of doing that. Really. Don't. >>>> >>> >>> Authentication, at least, has been in the community memcached release >>> for the last two micro releases: >>> http://code.google.com/p/memcached/wiki/ReleaseNotes143 >>> >>> If you need security labels and such, running separate processes would >>> seem to be the way to go. >> >> Yes, it is an approach to enforce strict separation between users. > > If "users" means users of your site, then are you going to apply > per-user access controls to the rows in your database, too?
Yes, see the page.14 of the slides: http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf Web users are authorized by apache/httpd and we can restrict privileges of web applications prior to its launch. We can restrict accesses to the filesystem, database and probably cached data based on the restricted privileges. > If "users" means admins running their own web apps, then run separate > instances. There are many other ways for multiple users of the same > memcached instance to cause each other trouble. Separate instances > with SASL auth to keep each to their own instance is the way to go at > this time. It is not my intention. Sorry for this confusion. Thanks, >> However, there are a few assumptions: >> - We don't need to consider any cases except for the strict-separation. >> - We need to assume web applications are bug/vulnerability free. >> >> In some cases, it is not suitable for the purpose. :( >> >> The development roadmap mentions about a modular approach in storage >> engine support. It seems to me similar approach may be possible in >> various kind of access control models. >> >>> Of course, security labels can also be applied >>> to network traffic, meaning that the authentication features are >>> redundant. :) >> >> Yes, SELinux provides an API to obtain privilege of the peer process >> for the given socket file descriptor (IIRC, Solaris also has similar >> API). We can use it instead of the authenticated username. >> >> Thanks, >> -- >> OSS Platform Development Division, NEC >> KaiGai Kohei<[email protected]> >> > -- OSS Platform Development Division, NEC KaiGai Kohei <[email protected]>
