[Planetlab-devel] opening up GetSliceTicket()

[David E. Eisenstat]

On Sat, 11 Aug 2007, Justin Samuel wrote:

> Back in May, you pointed us to the NodeManager API's GetSSHKeys() and 
> that's been working great for us. However, we now also need access to 
> this same information from outside of PlanetLab.
>
> As far as I'm aware there is currently no way to get these keys through 
> the PLC API. I've looked at the documentation and I only see methods for 
> retrieving one's own keys. --- Would it be possible to make available 
> something similar to GetSSHKeys() in the PLC API? What we ultimately 
> need are the public keys for either a single slice or those for all 
> slices the user can access.

You are correct that there is currently no way to achieve this without an 
administrator role.

Your request raises a larger policy issue, namely, the fact that there 
isn't a consensus about what information should and should not be 
available to users of PlanetLab. We've set policies on a 
component-by-component basis, and the result is that today's 
implementation has a number of inconsistencies. Since I didn't see the 
harm in making public keys public, I implemented and announced 
GetSSHKeys(), and no one complained. On the other hand, I believe no one 
(until you) has complained about the lack of access to public keys from 
the API. Another example is that the API won't return information to users 
about node <-> slice associations for slices to which they don't belong, 
while this information is mostly available to the general (read 
non-PlanetLab-using) public via CoMon.

My own (probably minority) view is that PlanetLab, as a research system, 
should be as transparent as possible so as not to hinder research. Others 
feel perhaps that defense-in-depth/privacy are important considerations, 
but AFAICT, the few security incidents we've faced would not have been 
prevented or even mitigated by keeping more secrets, and very little of 
the information the API tries to keep secret actually remains secret and 
inaccessible to a motivated user for very long.

If there are other arguments in favor of information hiding, I'd like to 
hear them.

-David

P.S.: I have a feeling that if I hadn't written this postscript, someone 
would propose making GetPersons()/user and GetKeys()/user return 
information about all users at sites with which the requester is 
associated. This doesn't solve the Stork team's problem since users of a 
single slice sometimes hail from multiple sites.