[Authentication] Item (property) visibility

[Stef Walter]

Michael Leupold wrote:
> Hi,
> 
> one thing that came to my mind while reading Stef's solution for the multi-
> session problem:
> 
> We didn't specify if several of the item properties should only be allowed to 
> be read (and also written) by sessions which unlocked the item. As it is, the 
> service doesn't actually know which session requests the property as it just 
> has the client's DBus address.
> 
> I wouldn't the global readability that much, but writeability is a problem in 
> my eyes.

As it currently stands, and was discussed previously on this list, the
only thing that is not readable before unlocking is the secret.

> Quick idea which I didn't really fully think through:
> 
> If we have a hit at the multi-session problem we could as well make the 
> collections children of session and allow them to only be accessed that way.

That's certainly one solution. I sort of touched on it before [1]. But
again, it'd be nice not to have to go there. There's a real benefit for
ease of use of having certain things in known places. For example the
default collection at a known object path.

However, as I proposed in my other email, the unlocking of stuff
wouldn't be tied to a session. The session would only govern transport
encryption. That's why I moved the BeginAuthenticate and family of
functions to the Service.

> I'm not quite sure if this is wouldn't be overkill though.

It may be necessary, but we should see if we can get around it without
compromising utility and simplicity of the design.

Cheers,

Stef