Re: permissions. ACLs? groups?
Jaap Karssenberg <j.g.karssenberg@student.utwente.nl> writes:
> Greetings
>
> The following might very well be absurd, I was daydreaming.
>
> When one allows users to create new groups within their own name
> space, wouldn't a logical next step to be to let users create their
> own users within their own name space (and within their own
> "permission space").
>
> For example I am user "user_a" on some box and I want to share this
> account with a friend of mine, but I do not want him to know my
> password and I want to restrict access to some personal files. Then
> I should be able to create a user "user_a:user_b" (I would be
> "user_a:root" myself), with his own password, and grant him some of
> the permissions that I was granted by "root", so I grant him to
> execute programs and access to a subdirectory of my homedir while I
> restrict access to some other subdirectory and my mail account.
I've been considering something like this. You could do this, in
another way, if we assume that user_b has an account then we can set
up file sharing using a translator (next post will outline the idea
I'm going to be working on) where you can grant on a per
{file,directory} basis constrained access.
Further, you could use an authentication mechanism like the users pgp
public key or other, as a partial authentication, beyond a login
mechanism.
> Of course a user could never grant permissions he doesn't have
> himself, only subsets of his own rights. Also there could be
> somekind of "admin" permissions, the permission to create ones own
> users (and/or groups) and the permission to edit certain groups or
> users. This would mean a decentralisation of the tyrannic power of
> "root". It would be very expandable for systems with a large amount
> of users all trying to cooperate with some other users, and all
> managing files for their various project groups. It could also be
> easily expanded to some kind of distrubuted system.
> I have no idea about the technical implementation of a permissions
> scheme, but a can envision a user having his own auth server which
> is slave to the systems root auth server. It seems hurdish to me to
> give a user as much freedom as possible without damaging the system.
I'm not sure, but I'm thinking that if an individual has permission to
connect a new translator to the filesystem, it would be difficult to
deny them the creation of their own translator which would allow them
to do this whether the admin wanted them to or not?
But that is perhaps the inverse of your proposal.
--
/^\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
Reply to: