Re: memcached permissions

[dormando]

Ahhah, thanks :)

Was uh, scared for a moment the that initial thread had been lost in time.

On Fri, 27 Aug 2010, KaiGai wrote:

> Sorry for the confusion.
> I intended to talk to maintainer of the standard security policy in
> SELinux.
>
> It is my job to maintain the selinux_engine.so module. :-)
>
> Thanks,
>
> On 8月27日, 午後6:02, dormando  wrote:
> > We're still working on merging down 1.6... but if this exists outside as
> > an engine nothing of us blocks you from using it for now.
> >
> > I sort of wonder a little about outright pulling it into the tree, since
> > that implies we have to maintain it.
> >
> >
> >
> > On Fri, 27 Aug 2010, KaiGai Kohei wrote:
> > > BTW, how about getting inclusion of this patch?
> >
> > > (2010/08/16 14:38), KaiGai Kohei wrote:
> > > > The attached patch is a revised version of memcached permissions.
> >
> > > > The 'calculate' permission has gone, and INCR/DECR requires us
> > > > both of 'read' and 'write' permissions.
> > > > It means we should switch domain of the client process when we
> > > > need special treatments to unaccessable items; something like
> > > > trusted procedures.
> >
> > > > Rest of the patch is not changed.
> >
> > > > (2010/08/05 9:20), KaiGai Kohei wrote:
> > > >> (2010/08/04 10:25), Kelvin Edmison wrote:
> > > >>> I'm still not sure how allowing a 'calculate' permission would be 
> > > >>> helpful in
> > > >>> this case.  Incr and decr allow for incrementing and decrementing by 
> > > >>> any
> > > >>> amount.  There does not seem to be any real difference between that 
> > > >>> and
> > > >>> 'write' to me.
> >
> > > >> INCR and DECR allow users to set a numerical value according to 
> > > >> arithmetic
> > > >> rule, although SET allows to set a fully arbitrary value.
> > > >> If administrator want to allow users to modify a value in a limited 
> > > >> way,
> > > >> he can grant 'calculate' permission, instead of 'write' permission.
> >
> > > >> If we would be talking about RDBMS, it is possible to switch client's
> > > >> privileges during execution of a certain stored procedure.
> > > >> However, memcached does not have such a feature, so we need to consider
> > > >> more fine grained permissions.
> >
> > > >> BTW, I noticed a different viewpoint, although I didn't reach the idea 
> > > >> before.
> > > >> Since memcached does not have stored procedure, it might be a correct 
> > > >> answer
> > > >> that the client switches its privileges when it tries to modify 
> > > >> read-only
> > > >> values. Like set-uid programs in unix, SELinux has a feature to switch
> > > >> privileges of process on execve(2) time. It allows a small number of 
> > > >> trusted
> > > >> programs to write values, but prevents to modify items by others.
> >
> > > >>> If a strict security partitioning is desired, then perhaps a single
> > > >>> reference counter isn't feasible.  Would it not be better, from a 
> > > >>> security
> > > >>> point of view, to have individual counters for the different clients?
> > > >>> The clients would have 'create|read|write' permissions, and any 
> > > >>> overall
> > > >>> administrative app could have read-only permissions on all those 
> > > >>> counters to
> > > >>> collect and sum (or otherwise report) them?
> >
> > > >> If a strict security partitioning environment, it seems to me what you 
> > > >> introduced
> > > >> is reasonable.
> >
> > > >> Thanks,
> >
> > > >>> Kelvin
> >
> > > >>> On 02/08/10 1:45 AM, "KaiGai Kohei"    wrote:
> >
> > >  (2010/07/30 22:55), Kelvin Edmison wrote:
> > > > While I haven't yet read the patch, I would like to understand why 
> > > > there is
> > > > a need for a Calculate permission.  Why would someone be granted 
> > > > 'calculate'
> > > > permission but not 'write' permission?
> >
> > > > Kelvin
> >
> > >  The issue depends on individual user's requirement of security.
> > >  If they want not to leak anything over the security domains,
> > >  they should grant the 'calculate' permission on everybody who
> > >  already have both 'read' and 'write' permissions.
> > >  It it equivalent to these permissions.
> > >  However, it may lack flexibility in configuration of access
> > >  controls, if users don't consider 'INCR' and 'DECR' are risk
> > >  information leaks/manipulations.
> > >  For example, it is not a rare case that we don't want to expose
> > >  individual client's items, but want to control a shared reference
> > >  counter.
> >
> > >  Ideally, I'd like to define more fine grained permissions to
> > >  distinguish a security sensitive operations and others.
> > >  But here is limitation of protocol. We cannot automatically
> > >  determine what is security sensitive data and what is not.
> >
> > >  Thanks,
> >
> > > > On 30/07/10 12:49 AM, "KaiGai Kohei"     
> > > > wrote:
> >
> > > >> I'll mainly submit the patch and message to SELinux community,
> > > >> but please don

Re: memcached permissions

[KaiGai]

Sorry for the confusion.
I intended to talk to maintainer of the standard security policy in
SELinux.

It is my job to maintain the selinux_engine.so module. :-)

Thanks,

On 8月27日, 午後6:02, dormando  wrote:
> We're still working on merging down 1.6... but if this exists outside as
> an engine nothing of us blocks you from using it for now.
>
> I sort of wonder a little about outright pulling it into the tree, since
> that implies we have to maintain it.
>
>
>
> On Fri, 27 Aug 2010, KaiGai Kohei wrote:
> > BTW, how about getting inclusion of this patch?
>
> > (2010/08/16 14:38), KaiGai Kohei wrote:
> > > The attached patch is a revised version of memcached permissions.
>
> > > The 'calculate' permission has gone, and INCR/DECR requires us
> > > both of 'read' and 'write' permissions.
> > > It means we should switch domain of the client process when we
> > > need special treatments to unaccessable items; something like
> > > trusted procedures.
>
> > > Rest of the patch is not changed.
>
> > > (2010/08/05 9:20), KaiGai Kohei wrote:
> > >> (2010/08/04 10:25), Kelvin Edmison wrote:
> > >>> I'm still not sure how allowing a 'calculate' permission would be 
> > >>> helpful in
> > >>> this case.  Incr and decr allow for incrementing and decrementing by any
> > >>> amount.  There does not seem to be any real difference between that and
> > >>> 'write' to me.
>
> > >> INCR and DECR allow users to set a numerical value according to 
> > >> arithmetic
> > >> rule, although SET allows to set a fully arbitrary value.
> > >> If administrator want to allow users to modify a value in a limited way,
> > >> he can grant 'calculate' permission, instead of 'write' permission.
>
> > >> If we would be talking about RDBMS, it is possible to switch client's
> > >> privileges during execution of a certain stored procedure.
> > >> However, memcached does not have such a feature, so we need to consider
> > >> more fine grained permissions.
>
> > >> BTW, I noticed a different viewpoint, although I didn't reach the idea 
> > >> before.
> > >> Since memcached does not have stored procedure, it might be a correct 
> > >> answer
> > >> that the client switches its privileges when it tries to modify read-only
> > >> values. Like set-uid programs in unix, SELinux has a feature to switch
> > >> privileges of process on execve(2) time. It allows a small number of 
> > >> trusted
> > >> programs to write values, but prevents to modify items by others.
>
> > >>> If a strict security partitioning is desired, then perhaps a single
> > >>> reference counter isn't feasible.  Would it not be better, from a 
> > >>> security
> > >>> point of view, to have individual counters for the different clients?
> > >>> The clients would have 'create|read|write' permissions, and any overall
> > >>> administrative app could have read-only permissions on all those 
> > >>> counters to
> > >>> collect and sum (or otherwise report) them?
>
> > >> If a strict security partitioning environment, it seems to me what you 
> > >> introduced
> > >> is reasonable.
>
> > >> Thanks,
>
> > >>> Kelvin
>
> > >>> On 02/08/10 1:45 AM, "KaiGai Kohei"    wrote:
>
> >  (2010/07/30 22:55), Kelvin Edmison wrote:
> > > While I haven't yet read the patch, I would like to understand why 
> > > there is
> > > a need for a Calculate permission.  Why would someone be granted 
> > > 'calculate'
> > > permission but not 'write' permission?
>
> > > Kelvin
>
> >  The issue depends on individual user's requirement of security.
> >  If they want not to leak anything over the security domains,
> >  they should grant the 'calculate' permission on everybody who
> >  already have both 'read' and 'write' permissions.
> >  It it equivalent to these permissions.
> >  However, it may lack flexibility in configuration of access
> >  controls, if users don't consider 'INCR' and 'DECR' are risk
> >  information leaks/manipulations.
> >  For example, it is not a rare case that we don't want to expose
> >  individual client's items, but want to control a shared reference
> >  counter.
>
> >  Ideally, I'd like to define more fine grained permissions to
> >  distinguish a security sensitive operations and others.
> >  But here is limitation of protocol. We cannot automatically
> >  determine what is security sensitive data and what is not.
>
> >  Thanks,
>
> > > On 30/07/10 12:49 AM, "KaiGai Kohei"     wrote:
>
> > >> I'll mainly submit the patch and message to SELinux community,
> > >> but please don't hesitate to comment anything from memcached
> > >> community.
> > >> 
>
> > >> The attached patch adds policies to support access controls
> > >> on key-value items managed by memcached with SELinux engine.
>
> > >> Nowadays, various kind of key-value-stores support memcached
> > >> compatible protocol as a de-facto standard. So, it will be a
> > >> reasonable start to cons

Surge 2010 Early Registration ends Tuesday!

[Jason Dixon]

Early Bird Registration for Surge Scalability Conference 2010 ends next
Tuesday, August 31.  We have a killer lineup of speakers and architects
from across the Internet.  Listen to experts talk about the newest
methods and technologies for scaling your Web presence.

http://omniti.com/surge/2010/register

This year's event is all about the challenges faced (and overcome) in
real-life production architectures.  Meet the engineering talent from
some of the best and brightest throughout the Internet:

John Allspaw, Etsy
Theo Schlossnagle, OmniTI
Bryan Cantrill, Joyent
Rasmus Lerdorf, creator of PHP
Tom Cook, Facebook
Benjamin Black, fast_ip
Christopher Brown, Opscode
Artur Bergman, Wikia
Baron Schwartz, Percona
Paul Querna, Cloudkick

Surge 2010 takes place at the Tremont Grand Historic Venue on Sept 30
and Oct 1, 2010 in Baltimore, MD.  Register NOW for the Early Bird
discount and guarantee your seat to this year's event!


-- 
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.com
443.325.1357 x.241

Re: Consistent hashing in PHP and Java

[Matt Ingenthron]

Hi Vicente,

Vicente Aguilar wrote:

Hi

At work we're setting up a multi-layered cluster with a 1st line of 
web/proxy/cache servers (nginx+memcached) and several layers of 
PHP-FPM and Tomcat application servers. At the moment we're using 
memcached just to cache raw HTML pages, not serialized objects: upon a 
request nginx checks if that URL (key) is on memcached and then serves 
it, else it proxies the request to the appropriate app server which 
serves it and saves it to memcached. Pretty basic memcached usage.


The problem is that we can't get the PHP, Java and nginx 
implementations to work together, the PHP and Java consistent hashing 
algorithms don't seem to match.


We (Dustin Sallings and Steve Yen mainly) did a lot of testing in 
spymemcached to ensure the hashing was the same between it and libketama 
in the most recent release.  There is a very large test of these in 
spymemcached.  In the process a bug was found and fixed, but it was a 
very minor bug.


It was compared to what libmemcached is doing with it's hashing and it's 
been well verified.  More below...




We're using:

- nginx: http://wiki.nginx.org/NginxHttpUpstreamConsistentHash 
 
- PHP: PECL:memcache http://pecl.php.net/package/memcache

- Java: spymemcached http://code.google.com/p/spymemcached/

Both the nginx and PHP implementations match, any HTML representation 
saved by PHP is retrieved by nginx from the same memcached server; but 
spymemcached's implementation seems to be different and with 2 
memcached server only matches 50% of the time, so it's a completely 
different algorithm and the matches are random. We're using the nginx 
patch and PECL:memcached with their default configuration, and as for 
spymemcached we've tried the NATIVE_HASH, CRC32_HASH and KETAMA_HASH 
algorithms but none of them matches nginx' and PHP's hashing.


Anybody else here is using memcached in Java and PHP and got them to 
work together? I've searched the list and this question has been 
raised several times but haven't find any definitive answer, just the 
obvious "different libraries may use different hashing 
implementations". We don't mind switching to other libraries.


Assuming you're using the latest spymemcached (which was released some 
time ago) and a recent pecl/memcached, at least those two should work 
together.  The PHP level wasn't, but the libmemcached ketama and 
spymemcached ketama are well tested.


With only two servers, nearly anything could make it be 50% off but it 
almost sounds like one client is seeing one of the servers as down.  In 
a ketama world, that'd mean put all of it on the remaining up servers 
(the other one in your case).


The only other thing to be careful with is perhaps the key (which seems 
to be a URL in your case?) is getting truncated or treated differently 
in different places?


Sorry I don't have any clear answers here, but I can say it's been 
tested and SHOULD work.


- Matt

Re: Help Needed - Rails Cache - Time Based

[moses wejuli]

thanks but i'm unavailable at the moment.

On 11 July 2010 10:43, Ajmal  wrote:

> Hello Sir,
>
> We are from India a small Web development company... I was search in
> the web for time based caching concept in rails.
>
> We have a small issue...
>
> what we are having is a home page with few iframes(with stock data
> from other websites)
>
> the loading time is high since data is got from other websites and
> displayed.
>
> We would like to cache the page as a pure html and display every say 5
> min
>
> ie the the rails home page is cached and stored as html so the output
> for normal users will be a plain html page which will be real fast.
>
> and every 5 min a new cache page is created deleting the old page...
>
> Could you help us and give an idea how we can achieve them..
>
> Thanks

Re: memcached permissions

[dormando]

We're still working on merging down 1.6... but if this exists outside as
an engine nothing of us blocks you from using it for now.

I sort of wonder a little about outright pulling it into the tree, since
that implies we have to maintain it.

On Fri, 27 Aug 2010, KaiGai Kohei wrote:

> BTW, how about getting inclusion of this patch?
>
> (2010/08/16 14:38), KaiGai Kohei wrote:
> > The attached patch is a revised version of memcached permissions.
> >
> > The 'calculate' permission has gone, and INCR/DECR requires us
> > both of 'read' and 'write' permissions.
> > It means we should switch domain of the client process when we
> > need special treatments to unaccessable items; something like
> > trusted procedures.
> >
> > Rest of the patch is not changed.
> >
> > (2010/08/05 9:20), KaiGai Kohei wrote:
> >> (2010/08/04 10:25), Kelvin Edmison wrote:
> >>> I'm still not sure how allowing a 'calculate' permission would be helpful 
> >>> in
> >>> this case.  Incr and decr allow for incrementing and decrementing by any
> >>> amount.  There does not seem to be any real difference between that and
> >>> 'write' to me.
> >>>
> >> INCR and DECR allow users to set a numerical value according to arithmetic
> >> rule, although SET allows to set a fully arbitrary value.
> >> If administrator want to allow users to modify a value in a limited way,
> >> he can grant 'calculate' permission, instead of 'write' permission.
> >>
> >> If we would be talking about RDBMS, it is possible to switch client's
> >> privileges during execution of a certain stored procedure.
> >> However, memcached does not have such a feature, so we need to consider
> >> more fine grained permissions.
> >>
> >> BTW, I noticed a different viewpoint, although I didn't reach the idea 
> >> before.
> >> Since memcached does not have stored procedure, it might be a correct 
> >> answer
> >> that the client switches its privileges when it tries to modify read-only
> >> values. Like set-uid programs in unix, SELinux has a feature to switch
> >> privileges of process on execve(2) time. It allows a small number of 
> >> trusted
> >> programs to write values, but prevents to modify items by others.
> >>
> >>> If a strict security partitioning is desired, then perhaps a single
> >>> reference counter isn't feasible.  Would it not be better, from a security
> >>> point of view, to have individual counters for the different clients?
> >>> The clients would have 'create|read|write' permissions, and any overall
> >>> administrative app could have read-only permissions on all those counters 
> >>> to
> >>> collect and sum (or otherwise report) them?
> >>>
> >> If a strict security partitioning environment, it seems to me what you 
> >> introduced
> >> is reasonable.
> >>
> >> Thanks,
> >>
> >>> Kelvin
> >>>
> >>> On 02/08/10 1:45 AM, "KaiGai Kohei"wrote:
> >>>
>  (2010/07/30 22:55), Kelvin Edmison wrote:
> > While I haven't yet read the patch, I would like to understand why 
> > there is
> > a need for a Calculate permission.  Why would someone be granted 
> > 'calculate'
> > permission but not 'write' permission?
> >
> > Kelvin
> >
>  The issue depends on individual user's requirement of security.
>  If they want not to leak anything over the security domains,
>  they should grant the 'calculate' permission on everybody who
>  already have both 'read' and 'write' permissions.
>  It it equivalent to these permissions.
>  However, it may lack flexibility in configuration of access
>  controls, if users don't consider 'INCR' and 'DECR' are risk
>  information leaks/manipulations.
>  For example, it is not a rare case that we don't want to expose
>  individual client's items, but want to control a shared reference
>  counter.
> 
>  Ideally, I'd like to define more fine grained permissions to
>  distinguish a security sensitive operations and others.
>  But here is limitation of protocol. We cannot automatically
>  determine what is security sensitive data and what is not.
> 
>  Thanks,
> 
> > On 30/07/10 12:49 AM, "KaiGai Kohei" wrote:
> >
> >> I'll mainly submit the patch and message to SELinux community,
> >> but please don't hesitate to comment anything from memcached
> >> community.
> >> 
> >>
> >> The attached patch adds policies to support access controls
> >> on key-value items managed by memcached with SELinux engine.
> >>
> >> Nowadays, various kind of key-value-stores support memcached
> >> compatible protocol as a de-facto standard. So, it will be a
> >> reasonable start to consider the protocol to control accesses
> >> from clients; typically web applications.
> >>
> >>   
> >> http://github.com/memcached/memcached/blob/master/doc/protocol.txt
> >>
> >> 1) new permissions
> >>
> >> This patch adds 'kv_item' class with the following permissions
> >>>

Re: memcached permissions

[KaiGai Kohei]

BTW, how about getting inclusion of this patch?

(2010/08/16 14:38), KaiGai Kohei wrote:
> The attached patch is a revised version of memcached permissions.
> 
> The 'calculate' permission has gone, and INCR/DECR requires us
> both of 'read' and 'write' permissions.
> It means we should switch domain of the client process when we
> need special treatments to unaccessable items; something like
> trusted procedures.
> 
> Rest of the patch is not changed.
> 
> (2010/08/05 9:20), KaiGai Kohei wrote:
>> (2010/08/04 10:25), Kelvin Edmison wrote:
>>> I'm still not sure how allowing a 'calculate' permission would be helpful in
>>> this case.  Incr and decr allow for incrementing and decrementing by any
>>> amount.  There does not seem to be any real difference between that and
>>> 'write' to me.
>>>
>> INCR and DECR allow users to set a numerical value according to arithmetic
>> rule, although SET allows to set a fully arbitrary value.
>> If administrator want to allow users to modify a value in a limited way,
>> he can grant 'calculate' permission, instead of 'write' permission.
>>
>> If we would be talking about RDBMS, it is possible to switch client's
>> privileges during execution of a certain stored procedure.
>> However, memcached does not have such a feature, so we need to consider
>> more fine grained permissions.
>>
>> BTW, I noticed a different viewpoint, although I didn't reach the idea 
>> before.
>> Since memcached does not have stored procedure, it might be a correct answer
>> that the client switches its privileges when it tries to modify read-only
>> values. Like set-uid programs in unix, SELinux has a feature to switch
>> privileges of process on execve(2) time. It allows a small number of trusted
>> programs to write values, but prevents to modify items by others.
>>
>>> If a strict security partitioning is desired, then perhaps a single
>>> reference counter isn't feasible.  Would it not be better, from a security
>>> point of view, to have individual counters for the different clients?
>>> The clients would have 'create|read|write' permissions, and any overall
>>> administrative app could have read-only permissions on all those counters to
>>> collect and sum (or otherwise report) them?
>>>
>> If a strict security partitioning environment, it seems to me what you 
>> introduced
>> is reasonable.
>>
>> Thanks,
>>
>>> Kelvin
>>>
>>> On 02/08/10 1:45 AM, "KaiGai Kohei"wrote:
>>>
 (2010/07/30 22:55), Kelvin Edmison wrote:
> While I haven't yet read the patch, I would like to understand why there 
> is
> a need for a Calculate permission.  Why would someone be granted 
> 'calculate'
> permission but not 'write' permission?
>
> Kelvin
>
 The issue depends on individual user's requirement of security.
 If they want not to leak anything over the security domains,
 they should grant the 'calculate' permission on everybody who
 already have both 'read' and 'write' permissions.
 It it equivalent to these permissions.
 However, it may lack flexibility in configuration of access
 controls, if users don't consider 'INCR' and 'DECR' are risk
 information leaks/manipulations.
 For example, it is not a rare case that we don't want to expose
 individual client's items, but want to control a shared reference
 counter.

 Ideally, I'd like to define more fine grained permissions to
 distinguish a security sensitive operations and others.
 But here is limitation of protocol. We cannot automatically
 determine what is security sensitive data and what is not.

 Thanks,

> On 30/07/10 12:49 AM, "KaiGai Kohei" wrote:
>
>> I'll mainly submit the patch and message to SELinux community,
>> but please don't hesitate to comment anything from memcached
>> community.
>> 
>>
>> The attached patch adds policies to support access controls
>> on key-value items managed by memcached with SELinux engine.
>>
>> Nowadays, various kind of key-value-stores support memcached
>> compatible protocol as a de-facto standard. So, it will be a
>> reasonable start to consider the protocol to control accesses
>> from clients; typically web applications.
>>
>>   http://github.com/memcached/memcached/blob/master/doc/protocol.txt
>>
>> 1) new permissions
>>
>> This patch adds 'kv_item' class with the following permissions
>>  - create
>>  - getattr
>>  - setattr
>>  - remove
>>  - relabelfrom
>>  - relabelto
>>  - read
>>  - write
>>  - append
>>  - calculate
>>
>>Most of permission works as literal.
>>On the 'SET' or 'CAS' operations, it creates a new item when here
>>is no items with same kye. In this case, 'create' permission shall
>>be checked. Elsewhere, 'write' permission shall be checked on the
>>   

Consistent hashing in PHP and Java

[Vicente Aguilar]

Hi

At work we're setting up a multi-layered cluster with a 1st line of 
web/proxy/cache servers (nginx+memcached) and several layers of PHP-FPM and 
Tomcat application servers. At the moment we're using memcached just to cache 
raw HTML pages, not serialized objects: upon a request nginx checks if that URL 
(key) is on memcached and then serves it, else it proxies the request to the 
appropriate app server which serves it and saves it to memcached. Pretty basic 
memcached usage.

The problem is that we can't get the PHP, Java and nginx implementations to 
work together, the PHP and Java consistent hashing algorithms don't seem to 
match. 

We're using:

- nginx: http://wiki.nginx.org/NginxHttpUpstreamConsistentHash 
- PHP: PECL:memcache http://pecl.php.net/package/memcache
- Java: spymemcached http://code.google.com/p/spymemcached/

Both the nginx and PHP implementations match, any HTML representation saved by 
PHP is retrieved by nginx from the same memcached server; but spymemcached's 
implementation seems to be different and with 2 memcached server only matches 
50% of the time, so it's a completely different algorithm and the matches are 
random. We're using the nginx patch and PECL:memcached with their default 
configuration, and as for spymemcached we've tried the NATIVE_HASH, CRC32_HASH 
and KETAMA_HASH algorithms but none of them matches nginx' and PHP's hashing.

Anybody else here is using memcached in Java and PHP and got them to work 
together? I've searched the list and this question has been raised several 
times but haven't find any definitive answer, just the obvious "different 
libraries may use different hashing implementations". We don't mind switching 
to other libraries.

Thanks in advance.

Regards

-- 
 Vicente Aguilar  | http://www.bisente.com