[PATCH] Request for adding internal meta-data support to KIO...

[Rolf Eike Beer]

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.
> > 
> > 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 such
> > 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.
> 
> 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 
idea was just: when you introduce the private metadata now someone else will 
come up with another good usecase soon. And short time later someone will find 
a way to screw up your ioslave in some funny way just by putting whatever 
value in the metadata cache.

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

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100429/c979eb12/attachment.sig>