-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/14/2011 01:46 AM, Alexander Knauf wrote:
> Hi Marc,
>
> Am 13.07.2011 18:35, schrieb Marc Petit-Huguenin:
> Hi Alexander,
>
> Just a quick question on this draft:
>
> Section 3 states that resource_name is the initial field and user_name is the
> second field in Kinds that will use the USER-CHAIN-ACL ACP, but the
> AccessControlListItem structure does not follow this rule as the first field
> is
> length. This is still implementable as the ACP code needs anyway to know how
> to
> parse the AccessControlListItem structure, but that requires it to be
> processed
> differently from the other shared resources. Was that the intent?
>> Well, the text of section 3 than might be unclear. If we write "... initial
>> field within the Kind data
>> structure...", we mean the "inner" Data structure of the Kind definition that
>> one carrying the application data, thus in the Access Control List list Kind
>> the
>> "AccessControlListData".
But for new Kinds (i.e. excluding the ACCESS-CONTROL-LIST Kind that needs to be
understood by the USER-CHAIN-ACL ACP code), the USER-CHAIN-ACL ACP code does not
know what is the inner Data structure, because the layout of the data is lost
for the peer receiving the Store request (which sees only a byte stream). For
example some Kinds use a longer "header" containing a type, or would not use an
inner Data structure at all, and so on.
I see in fact two solutions:
1. The resource_name and user_name are really the first fields, i.e.
USER-CHAIN-ACL looks something like this:
struct {
opaque to_user<0..2^16-1>;
KindId kind;
Boolean allow_delegation;
} AccessControlListData
struct {
opaque resource_name<0..2^16-1>;
opaque user_name<0..2^16-1>;
uint16 length;
AccessControlListData data;
} AccessControlListItem;
2. Add a new variable in the kind that contain the offset to the inner Data
structure, so e.g. with the original AccessControlListItem you can use a kind
description that looks something like this:
<kind-block>
<kind id=\"4026531841\"
xmlns:share=\"urn:ietf:params:xml:ns:p2p:config-base:share\">
<data-model>ARRAY</data-model>
<access-control>USER-PATTERN-MATCH</access-control>
<max-count>100</max-count>
<max-size>100</max-size>
<share:pattern>.*-conf-$USER@$DOMAIN</share:pattern>
<share:offset>2</share:offset>
</kind>
</kind-block>
There is a 3rd solution, which is to use ECMAScript scripts for each shared
resource so the ACP code always knows where the user_name and resource_name
values are in the byte stream, but I think it is a bad idea to use script as a
permanent solution, for reasons I explained in the Security Section of my draft.
With the text that is in your draft, there is no other solution than to release
a new version of the RELOAD implementation that understand each new shared
resource structure, and be sure that all peers use this new version before you
can start storing the new shared structure in the overlay. Depending on your
use case, that could be OK, but this need, IMO, to be clearly stated in your
draft (and in this case, it does not matter where the user_name and
resource_name variables are).
- --
Marc Petit-Huguenin
Personal email: [email protected]
Professional email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk4e/tUACgkQ9RoMZyVa61eQiQCeL2NCrL2JY0XNp/rl1JHQYgwB
bpsAnjNh+xEll8lwZV9zibfTp6qO9ZRA
=+cGn
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
