Hi Viven,<div><br></div><div>You proposal is very timely indeed. We've previously discuss the need of including (and somehow linking as an image) kernels and initrd files for Xen deployments. Also, as result of the security problem with context it is clear that opennebula should check access control for context files.</div>
<div><br></div><div>Our initial designs are in line with your proposal, and basically includes:</div><div><br></div><div>1.- Reuse of the Image Repository (greatly improved in 3.0)</div><div>2.- Reuse of the ACL and user/group mechanism in 3.0</div>
<div>3.- Extend image attributes to refer file in the repository</div><div> </div><div>About 1</div><div>KERNEL or CONTEXT files are defined as a new TYPE in the Image Repository. The specific behavior of each new type could be easily tuned in the image drivers</div>
<div><br></div><div>About 2</div><div>Specific permissions on files would be handled by the image repository, so access control will benefit from all the new Auth system. You could share kernels in a group of users for example, made them public...</div>
<div><br></div><div>About 3</div><div>The benefit of doing this in the OpenNebula core is that a VM will be reject at creation if it tries to access a kernel or context file without the appropriate permissions.</div><div>
<br></div><div>So basically we were thinking more in a coupled (in the OpenNebula daemon) implementation.</div><div><br></div><div><br></div><div>Cheers</div><div><br></div><div>Ruben</div><div><br><div class="gmail_quote">
On Fri, Jun 24, 2011 at 6:00 PM, Vivien Bernet-Rollande <span dir="ltr"><<a href="mailto:vivien.bernet-rollande@nexen.alterway.fr">vivien.bernet-rollande@nexen.alterway.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi everyone.<br>
<br>
I have recently deployed an installation of Open Nebula. Simple background : we're running Xen on Debian, with a custom TM driver that uses both NFS and iSCSI (sharing that TM driver is in our roadmap).<br>
<br>
I have encountered a few shortcomings. Some I have simply accepted for now, others I have bypassed as I could. One of them has to do with file management.<br>
<br>
I'll consider several types of files :<br>
- VM images.<br>
- kernels/initrd images.<br>
- contextualization files.<br>
<br>
Regarding VM images :<br>
If a non-privileged user wants to use his own images, he needs either :<br>
- a shell on the master host, and put his images as world readable.<br>
- to put his images on a public http/ftp server<br>
We found neither to be satisfying from the point of security.<br>
<br>
Regarding kernels/initrds there is no way fo a user to upload his kernels. Kernels must either be installed on all compute nodes, or on a shared file system.<br>
<br>
Regarding contextualization files, it's pretty much the same problem as with images.<br>
<br>
Basically, what I would like is the following :<br>
- all files that may be used in a template by a non privileged users are owned by oneadmin<br>
- all files that may be used in a template by a non privileged users are chmoded 600<br>
- all files used in a template are referenced by a file ID.<br>
Allowing end-users to manipulate system paths is a security nightmare.<br>
<br>
Basically, what I want is :<br>
- admins may manipulate images with a path<br>
- users are only allowed to use file ids (e.g. KERNEL="kernel-linux3.0.grsec" or an arbitrary id)<br>
- users may upload files through the API, possibly through sunstone<br>
<br>
I'm making the following proposition. This is not something I suggest should simply be added to the roadmap. This is something I (or someone else where I work) will be working on, and contribute back. Hence I'm looking for feedback on what the community thinks about it.<br>
<br>
There would be a new "file" API, with associated "onefile" command.<br>
"onefile create" would take a file parameter, and upload that file _through the API_.<br>
Oned would then save that file in a directory (/srv/cloud/files).<br>
Templates could then refer to those using their ids.<br>
<br>
Files may have key-value pairs associated with them, and onefile can manipulated these.<br>
<br>
There would be a "onefile update" command, which would allow a user to update a file, yet keep the same ID and key-value pairs.<br>
<br>
A file is read-only. A file is never written to by a VM, or oned, or anything.<br>
<br>
Admins may create a file with a "--local" flag. In that case, the path is sent to oned rather than the file, and oned copies the File. If the file is a symlink, the symlink is copied, rather than the file it links to.<br>
<br>
Anything parsing a template is updated to understand this idea of file id, and replace it the right value. If the template contains paths and was submitted by an untrusted user, a "permission denied" error is returned. This can be disabled or enabled to ensure compatibility in the oned.conf file.<br>
<br>
Contextualization may be done by selecting all files that have a certain value for a certain key (e.g. "role->mysql" or "vhost-><a href="http://www.example.com" target="_blank">www.example.com</a>"), or by specifying the file's id, or it's path if<br>
<br>
An image may be created from a file. The image repository needs to know how to import a file.<br>
<br>
A file may be uploaded compressed. It would make sense to store it compressed as well (or at least as a sparse file).<br>
<br>
I welcome any remarks or questions on this idea.<br>
<br>
-- <br>
Vivien Bernet-Rollande<br>
Systems& Networking Engineer<br>
Alter Way Hosting<br>
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/<u></u>listinfo.cgi/users-opennebula.<u></u>org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dr. Ruben Santiago Montero<br>Associate Professor (Profesor Titular), Complutense University of Madrid<br><br>URL: <a href="http://dsa-research.org/doku.php?id=people:ruben" target="_blank">http://dsa-research.org/doku.php?id=people:ruben</a><br>
Weblog: <a href="http://blog.dsa-research.org/?author=7" target="_blank">http://blog.dsa-research.org/?author=7</a><br>
</div>