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

[Vivien Bernet-Rollande]

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