[Pipet Devel] Access levels in VSH

[Brad Chapman]

> jarl van katwijk wrote:
>> 
>> We needed those to authorize DL's to login. Now this is where my 
problem
>> begins: who should be able to grant others access?
>> 
>> So we need some form of access level in the vsh system, how do we
>> organize them? I copied a 'root' system like unix uses, so only the 
1th DL
>> can authorize others. But maybe we do need a more sophisticated 
system,
>> something that not only allows DL's access, but also grants them the
> ability
>> to grant access to others.

Jeff wrote:
> I haven't thought about this at all.  I'm not a security expert, but 
wouldn't
> 'passable access/authentication' be opening up a pandora's box?  
You'll never
> know who has access to your system.
> 
> I think another thing to consider is whether or not a mere user can 
grant
> access.  Perhaps only the system administrator should be allowed to 
do this. 
> This is the opposite extreme of Jarl's proposal.  Thoughts?

It seems like Jarl is proposing a system like they implement (I think) 
in the MySQL database (and I guess in many other situations as well). 
The initial user (whoever is the system admin or whatever) gets root 
access to the database, and can thus do whatever they want, including 
using any databases and tables they want and assigning new users. Now, 
when a new user get assigned, they can be assigned with permissions to 
use certain databases and permission (or not) to authorize new users. 
I dig this scheme :-)
    I think you both described another system as well, in which only 
the root user can authorize new access. I don't think we need 
something this strict since the first system I described can be this 
strict (if the system admin wants it).
    So to kind of bring these two ideas together for vsh, whoever sets 
up vsh has a 'root' login that they can use to start up a dl. They can 
then use this login to assign new logins to users, and can pick 
optional permissions, including restricting access to only certain 
nodes (or other data) and allowing or disallowing creation of new 
users. Now these users can create new users, but don't have the option 
of passing on the ability to create to these subsequent users (this 
prevents the Pandora's box problem Jeff mentioned).
    What do you all think? How would the implementation for this be? 
Difficult?

Brad