On Thu, Dec 13, 2001 at 05:06:29PM +0100, Romano Giannetti wrote:
> > 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...)
I think generally temporary files should go to /tmp and not the home
directory, but yes, there may be reasons to write to specific files in
the home directory as well.
> > 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.
Why would the slave not be able to read/map dynamic libraries in my
sceeme? Such files should be readable by everyone, so I don't see the
problem?
With ACL support I don't see this beeing limited at all. The process can
be given any rights you desire before changing it's effective userid.
-- Ragnar Kjørstad Big Storage - 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/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:26 EST