Re: User-manageable sub-ids proposals

["Ragnar Kjørstad" <kernel@ragnark.vestdata.no>]

On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
> I am romano, uid 300.
> There is(/are) another(s) user, for example r-slave, uid 3001, no login
> shell, with home dir in ~romano/r-slave.

It would be so much nicer to be able to do this on-the-fly, rather than
having to create the user and it's home directory first.

However, I think one must first start with figguring out what
functionality we want:
1 do we want the "slave" to be able to read the users files
2 do we want the "slave" to be able to write the users files
3 do we want the "slave" to keep is own configuration files

And I think the answers are:
1. No. It would make it possible for broken/evil programs
   to steal your data.
2. Definitively not
3. No - it would cause different "slave" processes interact.
   It should rather use the users regular configuration files.

And we end up with a different solution:
olduid=getuid();
/* Allocate a uid with no privilegies */
slaveuid=setruid_slave(); 
set_acl("private-file", ACL_READ, slaveuid);
set_acl("private-log", ACL_APPEND, slaveuid);
seteuid(slaveuid);
exec("dangerous-program");


This should also be possible to implement with minimal impact. All you
need is a new systemcall to allocate a uid for the slave. This means you
need to reserve some uids for this purpose, but with 32bit uids......

A possible addon would be a systemcall to free the uid when it was not
in use anymore, so it can be reused safely. 

An alternative would be to not give the new uid access to the files, but
just open them before doing exec. This way it is safe to run multiple
slaves with the same uid at once, and it doesn't rely on ACLs! The
downside is that it needs cooperation from the dangerous-program, while
the above could work as long as the wrapper (e.g. a browser) took the
appropriate steps.


-- 
Ragnar Kjørstad
Big Storage