(2010/04/05 4:17), Trond Norbye wrote:
>
> On 2. apr. 2010, at 07.31, KaiGai Kohei wrote:
>
>> (2010/04/02 11:29), Dustin Sallings wrote:
>>> Can you submit this as a series of independent changes, or perhaps a
>>> just put up a repo somewhere?
>>>
>>> We appreciate the work, but we'll need to break it up into consumable
>>> chunks.
>>
>> http://github.com/kaigai/memcached-selinux
>>
>> I set up this repository.
>>
>> The 'master' branch is a clone of the Trond's engine tree.
>>
>> $ git clone git://github.com/kaigai/memcached-selinux.git
>> $ cd memcached-selinux
>> $ git diff origin/master origin/reworks_1
>> -> It adds get_socket_fd() server API to obtain socket file descriptor
>> for the given cookie.
>>
>
> I've applied this patch..
Thanks,
>> $ git diff origin/reworks_1 origin/reworks_2
>> -> It adds item_get_nkey() and item_get_ndata() engine APIs, to inject
>> security attribute as a part of values by intermediation modules
>> (such as bucket or selinux).
>>
>
> What is the primary motivation for doing this? I don't see why backends
> would "dynamically change" these values for an item. The reason I added
> a function to get the key and data was because one could imagine that
> they could be stored on different locations (or memory mapped data areas)...
> CAS is called through the api to allow the cas to be optional in the backend
> if you don't want to waste 8 bytes per item... From what I've seen earlier
> you chose to store your security information as a textual string after the
> key? you could still do that but then let nkey contain the number of bytes
> in the key, and keep the other information somewhere else..
What I try to do is to store the security information as a part of the value
for the secondary modules, rather than just after keys.
In this approach, the secondary module doesn't need special treatments on the
items with security information, because the it just stores the given value
as is.
As someone pointed out before, I don't think it is not good idea to handle
the security information specially and independently from existing keys and
values, because it is unclear whether the secondary modules pay mention about
this security properties.
If the secondary module see the security information just a part of values,
it shall be handled correctly. If not, it is just a bug in the secondary one.
So, I want to modify the value when it is delivered from the primary module
to the secondary one, and want to split up the item when it is delivered from
the primary module to the memcached core.
The existing get_item_data() allows the primary module to modify the pointer
of data field, although it might be an invention of new usage, but we cannot
fix up the length of the data field right now,
The purpose of get_item_ndata() is that the primary module inject its security
information transparently for both of the core memcached and the secondary
modules.
User
| ^
| | {key = "abcd", value = "foovarbaz"}
v |
Memcached
| ^
| | {key = "abcd", nkey=4, value = "foovarbaz", nbytes=9}
v |
Primary engine module
| ^
| | {key = "abcd", nkey=4, value = "secret\0foovarbaz", nbytes=16}
v | ^^^^^^^^ ... transparently injected
Secondary engine module <----> [it's item storage]
>> $ git diff origin/reworks_2 origin/reworks_3
>> -> It adds the 'features' field at engine_interface structure, to
>> inform what features are supported by the loaded module.
>>
>
> What are you going to use this information for???
> Your patch doesn't contain any use of the field making it hard for me to
> understand the use case..
Sorry, the upcoming selinux module shall see whether the secondary module
has persistent storage support, or not. It is a needed information to optimize
its performance and memory consumption.
If the secondary module has persistent storage support, the format of security
information must be portable, even if the memcached is rebooted or the data
files are copied.
The flat text representation (such as, "unclassified") is portable. It enables
us to understand security information of the items after rebooting, but needs
to parse when it makes access control decision.
If we can ensure duration of the item limited to memcached server process,
the security information is not necessary in text. For example, it can be
a pointer to the parsed security information for more quick access control
decision.
So, I would like to know what features are supported in the secondary module.
>> $ git diff origin/reworks_3 origin/reworks_4
>> -> It replaces settings.engine.v1->xxx(...) invocations by wrapper
>> functions.
>>
>
> The source code does not follow the same coding standard as the rest
> of memcached...
Does the coding standard mean tab, indent, case arc and others?
If so, I'll fix up them according to rest of memcached.
Or, are you saying the wrapper functions are not coding standard in the
memcached, so unnecessary?
Thanks,
--
KaiGai Kohei <[email protected]>
--
To unsubscribe, reply using "remove me" as the subject.
