That's why they have acl in ZoL, no?

just bring up a new filesystem for each container, with acl so only the owning container can use that fs, and you should be done, no?

To be clear, each container would have to have a unique uid for this to work, but together with Ralph's idea of a uid pool this would provide good isolation.
The reason for ZoL filesystems is to ensure isolation as well as the other benefits of zfs to docker...

Anyway, clusterhq seem to have a nice product called flocker, which might also be relevant for this.

On 06/06/2016 12:07 PM, John Hearns wrote:
Rob, I am not familair with wakari.io

However what you say about the Unix userid problem is very relevant to many 'shared infrastructure' projects and is a topic which comes up in discussions about them.
Teh concern there is, as you say, if the managers of the system have a global filesystem, with shared datasets, then if virtual clusters are created on the shared infrastructure, or if containers are used, then if the user have root access they can have privileges over the global filesystem.

You are making some very relevant points here.





On 5 June 2016 at 01:51, Rob Nagler <openmpi-wo...@q33.us> wrote:
Thanks! SLURM Elastic Computing seems like it might do the trick. I need to try it out. 

xCAT is interesting, too. It seems to be the HPC version of Salt'ed Cobbler. :)  I don't know that it's so important for our problem. We have a small cluster for testing against the cloud, primarily. I could see xCAT being quite powerful for large clusters. 

I'm not sure how to explain the Unix user id problem other than a gmail account does not have a corresponding Unix user id. Nor do you have one for your representation on this mailing list. That decoupling is important. The actual execution of unix processes on behalf of users of gmail, this mailing list, etc. run as a Unix single user. That's how JupyterHub containers run. When you click "Start Server" in JupyterHub, it starts a docker container as some system user (uid=1000 in our case), and the container is given access to the user's files via a Docker volume. The container cannot see any other user's files. 

In a typical HPC context, the files are all in /home/<unix-user>. The "containment" is done by normal Unix file permissions. It's very easy, but it doesn't work for web apps as described above. Even being able to list all the other users on a system (via "ls /home") is a privacy breach in a web app.

Rob


_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: http://www.open-mpi.org/community/lists/users/2016/06/29369.php



_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: http://www.open-mpi.org/community/lists/users/2016/06/29377.php


Reply via email to