[ovs-dev] [PATCH 2/2] xenserver: Support network names with spaces
Ian Campbell
Ian.Campbell at citrix.com
Tue Mar 2 13:50:36 UTC 2010
On Tue, 2010-03-02 at 11:13 +0000, Justin Pettit wrote:
> On Mar 2, 2010, at 2:09 AM, Ian Campbell wrote:
>
> > On Tue, 2010-03-02 at 02:02 +0000, Justin Pettit wrote:
> >>
> >> Note that this fix is really just a temporary workaround, since the
> >> changes to the "vif" script potentially have security issues. Ben has
> >> a patch in flight which reworks a lot of this code.
> >
> > It's a bit terrifying -- can we not just wait for Ben's fix?
>
> The reason for the rush is that we are on a tight deadline to deliver
> something testable by Wednesday and in it's current incarnation, it
> breaks something pretty fundamental (having a network name with spaces
> is the default when creating an internal network in XenCenter). Even
> so, I wouldn't normally suggest something like this, but the only
> users that I could think of that can create networks (whether through
> XenCenter or xe) already have root access on the XenServer. You're
> clearly the domain expert here, so I may be missing another avenue, of
> course.
XenServer 5.6 has role-based access control so not all root access (via
the XenAPI at least) is equal. To be honest I'm not sure what the
available roles are but I worry that someone might be able to escalated
their supposed privilege. (I'm pretty sure ssh/console login is a
specific separate role).
> I haven't had a chance to look at Ben's fix yet, but he wasn't certain
> that it wasn't going to have its own problems with having to taint
> user input. Until we have something that we're certain actually fixes
> the problem and has the security implications thought through, it
> seemed reasonable to at least allow the default case to work in a
> feature branch. All that said, if this still gives you the
> heebie-jeebies*, I'm happy to hold off if you don't think it's the
> bee's knees.
Perhaps we could leave it out for now? (Sorry, I couldn't find a
suitable rhyme). It's absence isn't a blocker for the current drop and
there's certainly scope for putting it back when we figure out the
issues.
What about adding an option to ovs-vsctl which takes a xenstore root and
pulls the extra keys out itself? Since ovs-vsctl is in a "proper"
language(*) it ought to be trivial to get the quoting correct. Something
like "set interface vif${DOMID}.${DEVID} xs-keys=${PRIVATE}".
It's a bit skanky to build the XS specific knowledge into ovs-vsctl
though. At the risk of complete over engineering things what about
allowing ovs-vsctl to call out to one or more hooks to provide this sort
of additional data for various commands?
(*) I was expecting python but it seems to have become a compiled binary
at some point...
Ian.
More information about the dev
mailing list