Yes, this could be nice.
> 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
Yes, but _by default_ the slave process could read only the files that you
have world readable (or group readable, if the slave is in the same group
than you, which probably is not a good idea). So you could decide wich file
it can access and which not.
> 2 do we want the "slave" to be able to write the users files
Generally no, but you can create a dir where the slave uid can create file
(think to a java applet that need temporary files, etc...)
> 3 do we want the "slave" to keep is own configuration files
Define the slave uid to have the same home dir than the main user...
>
> 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......
>
Yes, but then the slave process is very much _very_ limited. It could need
to read/map dynamic libraries, for example; with my approach the slave uid
processes are processes that have a full-level citizenship and that can do
anything a process can do, but under a different name than the user. Root
uses "nobody" to this extent sometime; my proposal is to extend this to
every (unprivileged) user in a safe way. Then, you can create a chrooted
environment for the new process and tailor the level of access it has
depending on the needs.
Romano
-- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 411 132 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/