zarutian+cap-talk at gmail.com
Mon Jan 19 18:50:48 EST 2009
2009/1/18 Rob Meijer <capibara at xs4all.nl>:
> On Sun, January 18, 2009 04:02, ross mcginnis wrote:
>> I've been wondering if you had a top-to-bottom cap based desktop what sort
>> of user account management system would be best implemented (this is w.r.t
>> a typical personal use computer with users in an every day setting, not
>> Would you emulate the traditional root/superuser account paradigm where
>> only one single entity has the authority to create and manage all the
>> other accounts (presumably this could be emulated by designing an account
>> creation object which is a trusted code object that tightly holds a
>> create-user cap)?
> A 'system-owner' might be an important concept. And from an individual
> users perspective, 'data-owner' might be an important concept.
> But for both, I feel that the possibility to delegate is essential.
>> Or perhaps design something more fluid (and a very big break from
>> standard) such as where you have a deliberately free create-user cap and
>> if any user possesses it they can create a new user and also they can
>> discretionally choose whether to pass the cap onto the newly created user
>> or not?
>> What other sort of arrangements are possible- eg, could you replace the
>> concept of user with some other concept?
> I feel that in a 'top to bottom' caps/POLA system, a new user account
> would in theory hold absolutely no authority. There seems no reason to
> disallow the creation of a user account at all. So a create-user cap
> should IMHO not only be free to delegate, there would not be any problem
> if each new user account would explicitly receive it on creation.
> There is actually much security to be gained from allowing each user to
> create new users with a subset of their privileges. If you disalow it as
> most systems do, you end up with people sharing their own single user
> account in order to get urgent work done.-snip-
I have seen exactly this, first hand.
> So in my view each and every
> user should be allowed to create new user accounts.
Hmm... how would you solve the possible name clash for the
receptionist? (aka the login program in *nix)
Two possibilities come to mind:
a) receptionist wide user identification numbers that increase
monotonusly for each new account added.
b) hierarchical nameing. (Like file system paths). Where the account
that Alice created for Bob would be
identified as /Alice/Bob
c) combination of the above. (Something I want to call replicator
serial numbering scheme)
Where the second account created by the fourth user of the system
would be identified as 4.2
>> This also raises other design questions regarding related issues such as
>> removing accounts.
> If you treat user accounts as regular objects, they should get garbage
> collected once there are no more references to it.
Or as in Capros/Coyotos/Eros/KeyKos/Gnosis: deleted when the user
objects space bank is ordered to self-destruct.
That is all for now.
More information about the cap-talk