[Libvir] [RFC PATCH] Solaris least privilege

[John Levon]

On Thu, Apr 24, 2008 at 03:59:26PM +0100, Daniel P. Berrange wrote:

> I'd just like to see if have an impl for Solaris - whether you happen to
> use it or not, is separate issue. Some people may be taking libvirt 

Fair enough.

> > When there's genuine configuration values that users need for something
> > enabled on Solaris, it will be in SMF anyway, so will need re-working on
> > the config backend in libvirt.
> 
> So you're not making use of any of the remote management features like 
> TLS and SASL/Kerberos ? I'd think at least users need the config to switch
> between which auth scheme they'd like to use, because the choice of TLS
> vs Kerberos is really  a deployment question for admins.

Today, we're not. When we do, as I said, we'll need libvirt changes to
understand SMF configuration instead of the config file, so we'll have
to fix up things there.

> > > > +int
> > > > +xenHavePrivilege()
> > > > +{
> > > > +#ifdef __sun
> > > > +	return priv_ineffect (PRIV_XVM_CONTROL);
> > > > +#else
> > > > +	return getuid () == 0;
> > > > +#endif
> > > > +}
> > > 
> > > As mentioned earlier, we probably want to move this into the util.c file
> > > and have the privilege name passed in as a parameter.
> > 
> > Could you explain further how you see this working?
> 
> Something like
> 
>     int virHavePrivilege(const char *);
> 
> Pass in  PRIV_XEN_CONTROL, and on Solaris have that check with your
> prvilege code, and on Linux just have it ignore the param and check
> the UID.  It is likely we'll do more fine grained checks based on 
> named privileges on Linux too

I'm not sure I like this. It's pushing out a Solaris-specific detail
("PRIV_XVM_CONTROL") to every user. Furthermore, I'm not sure about it
being generic either: PRIV_XVM_CONTROL wouldn't apply to qemu on
Solaris, or zones, or whatever.

> > This just adds a whole bunch of extra code to no clear advantage?
> 
> There's no extra code because virsh console already exists and isn't
> going away because it offers  a superset of what xenconsole does, by
> virtue of being portable

Sure there is:

 - code to spawn and run virt-console
 - all the current virsh console code in virt-console
 - the least-priv implementation in virt-console, duplicating xenconsole

Note the latter is going to be Xen-specific (indeed, Xen on Solaris
specific). There's no way I can avoid that.

Anyway, if you're set on this, I'm not entirely averse to it, I'm just
not sure I see the point.

regards,
john