[one-users] [RFC] Writing a file repository system for images, kernels, context files, and more

[Ruben S. Montero]

Hi Viven,

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.

Our initial designs are in line with your proposal, and basically includes:

1.- Reuse of the Image Repository (greatly improved in 3.0)
2.- Reuse of the ACL and user/group mechanism in 3.0
3.- Extend image attributes to refer file in the repository

About 1
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

About 2
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...

About 3
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.

So basically we were thinking more in a coupled (in the OpenNebula daemon)
implementation.


Cheers

Ruben

On Fri, Jun 24, 2011 at 6:00 PM, Vivien Bernet-Rollande <
vivien.bernet-rollande at nexen.alterway.fr> wrote:

> Hi everyone.
>
> 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).
>
> 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.
>
> I'll consider several types of files :
>  - VM images.
>  - kernels/initrd images.
>  - contextualization files.
>
> Regarding VM images :
> If a non-privileged user wants to use his own images, he needs either :
>  - a shell on the master host, and put his images as world readable.
>  - to put his images on a public http/ftp server
> We found neither to be satisfying from the point of security.
>
> 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.
>
> Regarding contextualization files, it's pretty much the same problem as
> with images.
>
> Basically, what I would like is the following :
>  - all files that may be used in a template by a non privileged users are
> owned by oneadmin
>  - all files that may be used in a template by a non privileged users are
> chmoded 600
>  - all files used in a template are referenced by a file ID.
> Allowing end-users to manipulate system paths is a security nightmare.
>
> Basically, what I want is :
>  - admins may manipulate images with a path
>  - users are only allowed to use file ids (e.g.
> KERNEL="kernel-linux3.0.grsec" or an arbitrary id)
>  - users may upload files through the API, possibly through sunstone
>
> 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.
>
> There would be a new "file" API, with associated "onefile" command.
> "onefile create" would take a file parameter, and upload that file _through
> the API_.
> Oned would then save that file in a directory (/srv/cloud/files).
> Templates could then refer to those using their ids.
>
> Files may have key-value pairs associated with them, and onefile can
> manipulated these.
>
> 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.
>
> A file is read-only. A file is never written to by a VM, or oned, or
> anything.
>
> 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.
>
> 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.
>
> Contextualization may be done by selecting all files that have a certain
> value for a certain key (e.g. "role->mysql" or "vhost->www.example.com"),
> or by specifying the file's id, or it's path if
>
> An image may be created from a file. The image repository needs to know how
> to import a file.
>
> A file may be uploaded compressed. It would make sense to store it
> compressed as well (or at least as a sparse file).
>
> I welcome any remarks or questions on this idea.
>
> --
> Vivien Bernet-Rollande
> Systems&  Networking Engineer
> Alter Way Hosting
>
> ______________________________**_________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/**listinfo.cgi/users-opennebula.**org<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>
>



-- 
Dr. Ruben Santiago Montero
Associate Professor (Profesor Titular), Complutense University of Madrid

URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20110627/1a734716/attachment-0003.htm>