Re: memcached and access control
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 kai...@ak.jp.nec.com (2010/01/06 15:14), Dustin wrote: On Jan 5, 10:06 pm, KaiGai Koheikai...@ak.jp.nec.com 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 kai...@ak.jp.nec.com
Re: memcached and access control
Obviously dissecting a memcached instance up into separate user kingdoms would have implied effect of slowing memcached down and adding unnecessary complexity. Unsure how much either would truly impact it however. Someone might want to substantiate this point. If you have a memcached need for multiple clients or different sites you are best running separate instances and using other 3rd party methods for attempting to secure memcached. 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? On Wed, Jan 6, 2010 at 5:35 AM, Henrik Schröder skro...@gmail.com wrote: 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 kai...@ak.jp.nec.com (2010/01/06 15:14), Dustin wrote: On Jan 5, 10:06 pm, KaiGai Koheikai...@ak.jp.nec.com 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 kai...@ak.jp.nec.com
Re: Issue 118 in memcached: Bad parameter -pthread being used on Solaris (instead of -pthreads)
Comment #6 on issue 118 by aavakian: Bad parameter -pthread being used on Solaris (instead of -pthreads) http://code.google.com/p/memcached/issues/detail?id=118 Just wanted to add a quick note that Sun Solaris comes with gcc 3.4.3, and even sunfreeware.com only provides gcc-3.4.6 as an alternative. Basically if we don't fix this in configure to support gcc 3.4.x, many people who get Solaris and don't specifically upgrade gcc themselves might have the problem I encoutered. The real issue is that 'gcc: unrecognized option `-pthread'' is a warning and not an error. If the person compiling memcached ignores that warning or does not notice it, and installs memcached, the results are insiduous (cache failures at small cache sizes etc...). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Problems with binary protocol and memcached PECL extension
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moon br...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
and what versions of libmemcached and pecl/memcached are you using? php
-i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php -i
can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
Re: Problems with binary protocol and memcached PECL extension
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php -i
can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
Re: Problems with binary protocol and memcached PECL extension
Try running your server from a console and add -vvv to the command
line. Does ti print out any progress?
On Wednesday, January 6, 2010, Jay Paroline boxmon...@gmail.com wrote:
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php
-i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
--
Trond Norbye
Re: memcached and access control
On Wed, Jan 6, 2010 at 2:48 AM, pub crawler pubcrawler@gmail.com wrote: Obviously dissecting a memcached instance up into separate user kingdoms would have implied effect of slowing memcached down and adding unnecessary complexity. Unsure how much either would truly impact it however. Someone might want to substantiate this point. If you have a memcached need for multiple clients or different sites you are best running separate instances and using other 3rd party methods for attempting to secure memcached. 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. On Wed, Jan 6, 2010 at 5:35 AM, Henrik Schröder skro...@gmail.com wrote: 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 kai...@ak.jp.nec.com (2010/01/06 15:14), Dustin wrote: On Jan 5, 10:06 pm, KaiGai Koheikai...@ak.jp.nec.com 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 kai...@ak.jp.nec.com
Re: memcached and access control
Aaron Stone wrote: On Wed, Jan 6, 2010 at 2:48 AM, pub crawler pubcrawler@gmail.com 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. Of course, security labels can also be applied to network traffic, meaning that the authentication features are redundant. :) - Matt
Re: memcached and access control
(2010/01/06 19:48), pub crawler wrote: Obviously dissecting a memcached instance up into separate user kingdoms would have implied effect of slowing memcached down and adding unnecessary complexity. Unsure how much either would truly impact it however. Someone might want to substantiate this point. If you have a memcached need for multiple clients or different sites you are best running separate instances and using other 3rd party methods for attempting to secure memcached. In the case when we can assume all the data are strictly separated, it is a reasonable approach to run separate memcached instances. However, it does not cover all the cases. 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? Sorry, it is unclear for me whether you suggest me to develop my own branch, or to work in the upstream. Basically, I'm not interested in making my branch apart from the community, because it does not utilize the benefit from OSS. Thanks, On Wed, Jan 6, 2010 at 5:35 AM, Henrik Schröderskro...@gmail.com wrote: 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 Koheikai...@ak.jp.nec.com (2010/01/06 15:14), Dustin wrote: On Jan 5, 10:06 pm, KaiGai Koheikai...@ak.jp.nec.comwrote: 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 Koheikai...@ak.jp.nec.com -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
Re: Multiple memcached servers with same data
I would believe Facebook does have geographic distribution of their memcached instances as well as all other app and web servers. Have you tried running a traceroute to their servers to see if there is some identifiable bottleneck between you and their servers? In our instance Facebook is 14 hops away on a fast cable modem on the US East Coast. Hops 11-14 balloon in response times to over 100ms average. If you get same route or end point hops with high latency this might be the issue: 11 FACEBOOK-INC.TenGigabitEthernet6-2.ar1.PAO2.gblx.net (67.17.162.38) 95.380 ms 95.452 ms 110.825 ms 12 ae0.bb01.pao1.tfbnw.net (74.119.76.132) 111.174 ms 111.260 ms 111.108 ms 13 ae5.br02.snc1.tfbnw.net (74.119.76.141) 110.847 ms ae5.br01.snc1.tfbnw.net (74.119.76.139) 110.763 ms ae5.br02.snc1.tfbnw.net (74.119.76.141) 110.832 ms 14 eth-17-17.csw01b.snc2.tfbnw.net (204.15.23.197) 116.560 ms eth-18-1.csw01b.snc2.tfbnw.net (204.15.21.125) 116.446 ms 116.315 ms On Wed, Jan 6, 2010 at 7:02 PM, Martin Bay m...@netomia.dk wrote: How come sites like facebook does not place memcached servers around the world with a live updated copy of their primary memcached servers? From Europe the facebook website is EXTREMELY slow.
Re: memcached and access control
(2010/01/07 8:32), Aaron Stone wrote: On Wed, Jan 6, 2010 at 2:48 AM, pub crawlerpubcrawler@gmail.com wrote: Obviously dissecting a memcached instance up into separate user kingdoms would have implied effect of slowing memcached down and adding unnecessary complexity. Unsure how much either would truly impact it however. Someone might want to substantiate this point. If you have a memcached need for multiple clients or different sites you are best running separate instances and using other 3rd party methods for attempting to secure memcached. 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. Sorry, It is unclear for me what you opposed to. (Sorry for the stupid reply, since English is not my native language...) If you opposed to making my own branch for access control purpose, I can understand its reason. If you opposed to add (optional) access control feature in the memcached, I'd like to see the reason why. Thanks, On Wed, Jan 6, 2010 at 5:35 AM, Henrik Schröderskro...@gmail.com wrote: 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 Koheikai...@ak.jp.nec.com (2010/01/06 15:14), Dustin wrote: On Jan 5, 10:06 pm, KaiGai Koheikai...@ak.jp.nec.comwrote: 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 Koheikai...@ak.jp.nec.com -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
Re: Problems with binary protocol and memcached PECL extension
This is very odd. If I run it from the command line (with or without
vv) it works as expected. If it starts from init.d it doesn't work.
[r...@rhd011 test]# /etc/init.d/memcached start
Starting memcached:[ OK ]
[r...@rhd011 test]# ps aux | grep memcached
101 29441 0.0 0.0 52448 1008 ?Ssl 20:07 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above does not work
[r...@rhd011 test]# /etc/init.d/memcached stop
Stopping memcached:[ OK ]
[r...@rhd011 test]# memcached -d -p 11211 -u memcached -m 64 -c 1024 -
P /var/run/memcached/memcached.pid
[r...@rhd011 test]# ps aux | grep memcached
101 29473 0.0 0.0 128064 996 ?Ssl 20:09 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above works
What the heck is the difference?
Jay
On Jan 6, 5:15 pm, Trond Norbye trond.nor...@gmail.com wrote:
Try running your server from a console and add -vvv to the command
line. Does ti print out any progress?
On Wednesday, January 6, 2010, Jay Paroline boxmon...@gmail.com wrote:
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php
-i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
--
Trond Norbye
Re: memcached and access control
(2010/01/07 11:07), Aaron Stone wrote: 2010/1/6 KaiGai Koheikai...@ak.jp.nec.com: (2010/01/07 9:14), Matt Ingenthron wrote: Aaron Stone wrote: On Wed, Jan 6, 2010 at 2:48 AM, pub crawlerpubcrawler@gmail.com 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 Koheikai...@ak.jp.nec.com -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
Re: Problems with binary protocol and memcached PECL extension
Ok, I'm officially semi-retarded. Apparently when I did a make install
of the latest version of memcached on our dev server it installed in /
usr/local/bin but the old version was still in /usr/bin -- when I ran
the daemon it ran from /usr/local/bin but the init.d script was
running it from /usr/bin
I made a sym link from /usr/bin to /usr/local/bin and restarted, and
it works like magic.
Jay
On Jan 6, 8:11 pm, Jay Paroline boxmon...@gmail.com wrote:
This is very odd. If I run it from the command line (with or without
vv) it works as expected. If it starts from init.d it doesn't work.
[r...@rhd011 test]# /etc/init.d/memcached start
Starting memcached: [ OK ]
[r...@rhd011 test]# ps aux | grep memcached
101 29441 0.0 0.0 52448 1008 ? Ssl 20:07 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above does not work
[r...@rhd011 test]# /etc/init.d/memcached stop
Stopping memcached: [ OK ]
[r...@rhd011 test]# memcached -d -p 11211 -u memcached -m 64 -c 1024 -
P /var/run/memcached/memcached.pid
[r...@rhd011 test]# ps aux | grep memcached
101 29473 0.0 0.0 128064 996 ? Ssl 20:09 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above works
What the heck is the difference?
Jay
On Jan 6, 5:15 pm, Trond Norbye trond.nor...@gmail.com wrote:
Try running your server from a console and add -vvv to the command
line. Does ti print out any progress?
On Wednesday, January 6, 2010, Jay Paroline boxmon...@gmail.com wrote:
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using?
php -i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
--
Trond Norbye
Re: memcached and access control
Aaron Stone wrote: Authentication, at least, has been in the community memcached release for the last two micro releases: http://code.google.com/p/memcached/wiki/ReleaseNotes143 It's a reasonable effort at keeping someone from writing to your cache. Surely they can still sniff the network to get your data. memcached with encryption is like a Ferrari with monster truck tires. Oops, I see I brought up a few things that were already in the thread, sorry! I think I agree here, but it may depend. In my opinion, with most things security related, the level of controls inserted should be proportional to the anticipated threat. The SASL implementation was put into memcached (and libmemcached and spymemcached) with a use case in mind. The very real use case that some people were trying to deal with in cloud deployments (and possibly some cloudy enterprise deployments) is a situation where it'd be hard to sniff the network, but it would be useful to ensure you know who someone is when they connect. This was covered back when it was released: http://code.google.com/p/memcached/wiki/SASLHowto http://blog.northscale.com/northscale-blog/2009/11/sasl-memcached-now-available.html http://blogs.sun.com/trond/entry/sasl_support_in_libmemcached There are some who run on clouds (public or private) who may need this kind of thing. There are others who run on pretty well controlled networks that don't need any of it. Right now, memcached provides both. I could see situations where one may need additional controls, but the kind of security controls that started the thread off (namely SELinux) which to me means security labels, usually means you don't trust non-audited programs and instead have the platform look after them. I guess KaiGai has taken that further with other application components though. 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. - Matt
Re: memcached and access control
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. It'd be incredibly inefficient on memory, compared to keeping the number of users down or even running multiple instances. -Dormando
Re: memcached and access control
(2010/01/07 11:39), Aaron Stone wrote: 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 Neat, you're really serious! Ok, so two ways I can see going about this: Use SASL authentication to validate each web user and then tag each key in memcached with a hash that can be verified to be owned by the user. Get and Set would check this tag before allowing a key to be written -- or build compound keys where the hash is the first part, so that separate user data exists each in its own namespace. In this case, you don't need protocol changes, only server changes to do more with the SASL information. It is my preference rather than the second idea, because it requires application to handle the security tag explicitly for each accesses, but most of access control feature generally performs below the surface. For example, we don't provide filesystem permissions any additional credentials for each read(2) or write(2) system call. If we don't assume a certain security model, in other word, if memcached provides a pluggable access control mechanism, it always does not need SASL authentication. For example, SELinux's security label of the peer process is a candidate. If we can identify the client (web application instance) in some way, memcached will be able to store the something identifier of the cached object. It may be called owner of the cached object (depending on the security model). Then, access control mechanism can provide its access control decision based on the client's identifier and object's identifier. It basically does not need protocol changes. However, we may want a new command to set/get security properties (or not only security properties) of the cached objects in the future. Thanks, Or, similar but without the SASL part, tagging each key with some secret value. If you have protected the database rows, then SELECT * FROM secret_memcached_keys will only return the keys the user is allowed to see. They would use those keys in a way similar to the CAS values; operations are only allowed to proceed if the secret tags match. In this case, you need a protocol change to carry the extra values. Anyhow, I'm not even close to a core contributer around here, so those are just some thoughts. 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 Koheikai...@ak.jp.nec.com -- OSS Platform Development Division, NEC KaiGai Koheikai...@ak.jp.nec.com -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
Re: memcached and access control
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? A few dozen users, yeah. Giving each registered user on a website his own private cache is just silly. Maybe in ten years when terabytes of ram are cheap.
Re: memcached and access control
(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
Which keys on which servers...
When using multiple memcached servers, the client software decides where to place a given key/value. What if I save key1=val1 using PHP functions addServer() and set(), and later want to fetch that value from perl? How do I know which memcached server to connect to? What if I save 100 values to 3 memcached servers, and then decide to add a 4th server? The keyhashserver will not match compared to the 3 server setup.
Re: memcached and access control
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. 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? 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_valuescramble_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. 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 -- Toru Maesaka d...@torum.net
Re: Which keys on which servers...
I believe the answer to both questions in this case is to enable consistent hashing. On 1/6/10 10:44 PM, Martin Bay wrote: What if I save key1=val1 using PHP functions addServer() and set(), and later want to fetch that value from perl? How do I know which memcached server to connect to? I believe (someone correct me otherwise) that PHP (pecl/memcached) and Perl both use the same consistent hashing algorithm. PECL/memcached actually gives you several choices for the hashing algorithm. Other libmmecached based clients will play nice with PECL/memcached. Now, you will have issues when storing complex data like arrays/objects as each language will need to serialize that data in a native format. What if I save 100 values to 3 memcached servers, and then decide to add a 4th server? The keyhashserver will not match compared to the 3 server setup. Consistent hashing uses a hashed wheel concept. Using this hashing system vastly reduce (not 100% eliminate) the cache/key realignment caused by adding/removing nodes. Brian. http://brian.moonspot.net/
