WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Finer access control framework over users, domains and o

To: Syunsuke HAYASHI <syunsuke@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Finer access control framework over users, domains and operations.
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Mon, 19 May 2008 11:21:19 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 May 2008 03:21:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <48311B5E.2060100@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <48311B5E.2060100@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Syunsuke HAYASHI writes ("[Xen-devel] Finer access control framework over 
users, domains and operations."):
> The current implementation exclusively allows root to control guest
> domains.  Guest administrators have to switch to root so they can
> bring their own guest domains up and down.

In most deployments this problem is addressed by the use of (for
example) a web-based management interface layered on top of the
underlying xm machinery.

Do your users really need an structurally very similar interface to
that provided by xm or libvirt ?  If so then yes maybe you will need
to write a policy-enforcing proxy but this would be a very large
amount of work and I wouldn't recommend it as an approach unless
unavoidable.

If the users don't need an interface that looks like (say) xm, then
the system's overall administrator can provide a much simpler higher
interface - and this is typically done with a bit of semi-custom
scripting based on a webserver, ssh with command-restricted keys, or
tools like `userv'[1] or `sudo'.

I think you may find that this ad-hoc approach provides both a quicker
route to solving your problem, and also a result which will be more
finely tuned to your needs.

Generalised policy framework systems are inevitably complex (and thus
often buggy!) and hard to write, and, paradoxically they often turn
out to be inflexible when one actually tries to use them.

> ioctl approach:

As you seem to have figured out, this is a non-starter.  Much of the
functionality you are trying to provide access to lives in user-space
management processes like xend and the lvm tools.

> <?xml version="1.0" ?>

And my final comment is: please do not use XML for configuration
files.  It is almost wholly unsuited for this use.

XML is utterly awful to edit by hand, doesn't diff well, is vastly
overcomplex, encourages overcomplex configuration structures, requires
a huge amount of parsing infrastructure, is very slow to parse, and is
just plain ugly.  Just a personal opinion.

Ian.

[1] GNU userv, a security boundary tool
   http://www.chiark.greenend.org.uk/~ian/userv/
 Full disclosure: I'm plugging my own software here :-).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel