[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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.

/ \

Reply to: