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

[Dawit A]

On Thursday, April 29, 2010 02:14:45 Rolf Eike Beer wrote:
> 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.

I do not understand this at all. How is that different from people screwing 
with the current system ? The can can do the very same thing right now and you 
can do nothing about it. But as I said, they have to do this purposefully.

> 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.

Again there is no way for a remote system to influence the meta-data system, 
internal or otherwise, right now unless the developer of an ioslave implicitly 
allows it to do so. As such I fail to see how you can protect against that by 
using special characters in the keyword. If the developer is going to expose 
it to influence by the remote system, what stops him from simply adding the 
keyword directly ? To me it is simply a pointless exercise since you cannot 
control what a developer will do in the end. What you are saying would make a 
great deal of sense if we automatically mapped meta-data sent by a remote 
system directly into our internal scheme, but we do not do that. 

Anyhow, in the end I have no objection to using special characters if that 
makes people feel safe about it. I just do not see the point of it. I could 
have as well said that the keyword would be "%kio~internal~0/1%" or 
"#kio~internal~0/1#" or "{kio~internal~0/1}" etc and all of those would be fine 
with me...

Regards,
Dawit A.