Re: [Libvir] [RFC PATCH] Solaris least privilege
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