[libvirt] LXC: making the private root filesystem more secure

[Dhaval Giani]

On Thu, Sep 11, 2008 at 02:42:46PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 10, 2008 at 03:10:53PM -0700, Balbir Singh wrote:
> > Daniel Veillard wrote:
> > > On Thu, Sep 04, 2008 at 12:50:35PM -0700, Dan Smith wrote:
> > >> DV> I just checked the libcgroup heaer file available under Fedora 9
> > >> DV> and I'm a bit afraid of the dependancy. They expose a lot of
> > >> DV> structure, some clearly incomplete, which means liking to it in its
> > >> DV> current state may turn into a problematic dependency.
> > >>
> > 
> > Could you please elaborate on the structure exposed. We are more then willing to
> > fix any incomplete information you are concerned about
> 
> I believe Daniel is refering to the struct's in your public header file.
> The embedded comments themselves  in libcgroup.h say that the structs 
> will need to be extended with more fields as cgroups gets more capabilities.
> Adding fields to a struct will change the ABI unless care is taken to 
> provide for extensibility. The cpu_controller and cg_group structs here 
> are of particular concern
>     
>     /*
>      * These data structures are heavily controller dependent, which means
>      * any changes (additions/removal) of configuration items would have to
>      *  be reflected in this library. We might implement a plugin
>      *  infrastructure, so that we can deal with such changes with ease.
>      */
>     
>     struct cpu_controller {
>             /*TODO: Add the cpu.usage file here, also need to automate this.*/
>             char *shares;   /* Having strings helps us write them to files */
>             /*
>              * XX: No it does not make a difference. It requires a fprintf anyway
>              * so it needs the qualifier.
>              */
>     };
>     
>     struct cg_group {
>             char *name;
>             uid_t tasks_uid;
>             gid_t tasks_gid;
>             uid_t admin_uid;
>             gid_t admin_gid;
>             struct cpu_controller cpu_config;
>     };
>     
>     /*
>      * A singly linked list suffices since we don't expect too many mount points
>      */
>     struct mount_table {
>             char *options;          /* Name(s) of the controller */
>             char *mount_point;      /* The place where the controller is mounted */
>             struct mount_table *next;
>     };
>     
>     /*
>      * Maintain a list of all group names. These will be used during cleanup
>      */
>     struct list_of_names {
>             char *name;
>             struct list_of_names *next;
>     };
>     

Hi Daniel,

I have patches posted to the list proposing to remove all these exposed
structures[1]. 

I am reposting those patches after updating them, so that they can get
reviewed and be included. These were structures which were leftover from
the original subsystem specific changes. Since then we have moved to a
generic design.

thanks,
-- 
regards,
Dhaval

[1]
http://sourceforge.net/mailarchive/message.php?msg_id=20080813105716.GE19247%40linux.vnet.ibm.com