--nextPart2851495.38SQcrh1s4
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

Am Mittwoch 28 April 2010 19:16:39 schrieb Dawit A:
> On Wednesday, April 28, 2010 11:57:57 Rolf Eike Beer wrote:
> > Am Mittwoch 28 April 2010 07:06:35 schrieb Dawit A:
> > > What was surprising here is that the above solution can be implemented
> > > very easily. With only one additional requirement to qualify meta-data
> > > as internal, we can use the existing method that ioslaves use to send
> > > meta-data back to applications to solve the issue. What is this
> > > requirement ? We simply state/assume that a meta-data whose key starts
> > > with the keyword
> > > "_kio_internal_" will be treated as an internal meta-data and handled
> > > separately from the regular meta-data container that holds values
> > > slated to be sent to applications. You can read the details of how
> > > this is supposed to work by either reading the attached patch or
> > > simply reading the changes I made to the DESIGN.metadata document
> > > which is included with the patch.
> >=20
> > I suggest using something that must not be a valid metadata identifier.
> > E.g. starting things with some (printable, ASCII) special character like
> > space, # or whatever. That way we can avoid that a server can inject su=
ch
> > things into the metadata cache. Otherwise you would have to filter out
> > any metadata from the server that starts with _kio_internal to make sure
> > it doesn't try to fool us into something.
>=20
> hmm... an interesting point but one that really does not apply in this
> case. If I understand it correctly, your concern is that a server will be
> able inject meta-data and force the ioslave to send it credentials it
> should not, correct ?

Well, I don't have thought about what will be the attack at the end at all.=
 My=20
idea was just: when you introduce the private metadata now someone else wil=
l=20
come up with another good usecase soon. And short time later someone will f=
ind=20
a way to screw up your ioslave in some funny way just by putting whatever=20
value in the metadata cache.

My point is less a thing that this (or any other) slave will do or not with=
=20
this data now or in one year. My point is that when this is some internal=20
state of whatever kind than we should under no way allow remote systems to=
=20
influence that in any way but through our code that does it explicitely. It=
's=20
the same like you make class members private instead of making them public =
and=20
hoping that noone will touch them if you name them _private_member_foo.

Eike

--nextPart2851495.38SQcrh1s4
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkvZI+EACgkQXKSJPmm5/E7c7gCglVB06fp/ZT+i3DZPF8FN+cvL
CEMAn23+FvSr5RlS1IkGXpP7bmoR3JY+
=bNuv
-----END PGP SIGNATURE-----

--nextPart2851495.38SQcrh1s4--