On 06-09-2010 14:18, Daniel P. Berrange wrote:
>> On Ubuntu, /etc/libvirt/libvirtd.conf is mode 0644? Should I be
>> worried about that? A quick glance in there doesn't reveal anything
>> that I'm uncomfortable disclosing.
> The /etc/libvirt directory itself should be 0700 though,
Nope, it's 0755
On Mon, Sep 06, 2010 at 02:03:08PM +0200, Soren Hansen wrote:
> On 06-09-2010 13:22, Daniel P. Berrange wrote:
> > On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote:
> >> On 06-09-2010 12:24, Daniel P. Berrange wrote:
> >>> On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
>
On 06-09-2010 13:22, Daniel P. Berrange wrote:
> On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote:
>> On 06-09-2010 12:24, Daniel P. Berrange wrote:
>>> On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
On 06-09-2010 11:17, Daniel P. Berrange wrote:
> Our goal is to
On Mon, Sep 06, 2010 at 10:17:17AM +0100, Daniel P. Berrange wrote:
> Our goal is to improve qemu://session's networking such that this isn't
> a reason to use qemu://system anymore.
BTW, some ideas we have for attacking this problem are
- Add support to network manager to create TAP devices on
On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote:
> On 06-09-2010 12:24, Daniel P. Berrange wrote:
> > On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
> >> On 06-09-2010 11:17, Daniel P. Berrange wrote:
> >>> Our goal is to improve qemu://session's networking such that
> >
On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote:
> On 06-09-2010 12:24, Daniel P. Berrange wrote:
> > On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
> >> On 06-09-2010 11:17, Daniel P. Berrange wrote:
> >>> Our goal is to improve qemu://session's networking such that
> >
On 06-09-2010 12:24, Daniel P. Berrange wrote:
> On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
>> On 06-09-2010 11:17, Daniel P. Berrange wrote:
>>> Our goal is to improve qemu://session's networking such that
>>> this isn't a reason to use qemu://system anymore
>> Fair enough, but
On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote:
> On 06-09-2010 11:17, Daniel P. Berrange wrote:
> > Our goal is to improve qemu://session's networking such that this
> > isn't a reason to use qemu://system anymore
>
> Fair enough, but when that happens, I'm supposing people won't h
On 06-09-2010 11:17, Daniel P. Berrange wrote:
> Our goal is to improve qemu://session's networking such that this
> isn't a reason to use qemu://system anymore
Fair enough, but when that happens, I'm supposing people won't have
access to the system-wide UNIX socket anymore.
> Enabing use of qem
On Fri, Sep 03, 2010 at 11:04:21PM +0200, Soren Hansen wrote:
> On 03-09-2010 15:59, Daniel Veillard wrote:
> >> diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
> >> index a945710..17e6ead 100644
> >> --- a/src/remote/remote_driver.c
> >> +++ b/src/remote/remote_driver.c
> >> @
On Fri, Sep 03, 2010 at 02:50:00PM -0600, Eric Blake wrote:
> On 09/03/2010 02:38 PM, Soren Hansen wrote:
> >>NACK, I don't think we should be changing this. If the user
> >>is unprivileged, it should always default to the unprivileged
> >>libvirtd, regardless of whether they are also authorized to
On 03-09-2010 15:59, Daniel Veillard wrote:
>> diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
>> index a945710..17e6ead 100644
>> --- a/src/remote/remote_driver.c
>> +++ b/src/remote/remote_driver.c
>> @@ -1086,7 +1086,7 @@ remoteOpen (virConnectPtr conn,
>> if (!conn->ur
On 09/03/2010 02:38 PM, Soren Hansen wrote:
NACK, I don't think we should be changing this. If the user
is unprivileged, it should always default to the unprivileged
libvirtd, regardless of whether they are also authorized to
connect to the privileged libvirtd (via socket permissions or
policykit
On 03-09-2010 16:08, Daniel P. Berrange wrote:
>> If no uri is passed to one of the virConnectOpen-ish calls, libvirt
>> attempts to autoprobe a sensible URI. Part of the current logic checks
>> for getuid() > 0, and if that check is succesful, a libvirtd daemon is
>> spawned. This patch replaces t
On Fri, Sep 03, 2010 at 03:28:58PM +0200, Soren Hansen wrote:
> If no uri is passed to one of the virConnectOpen-ish calls, libvirt
> attempts to autoprobe a sensible URI. Part of the current logic checks
> for getuid() > 0, and if that check is succesful, a libvirtd daemon is
> spawned. This patch
On Fri, Sep 03, 2010 at 03:28:58PM +0200, Soren Hansen wrote:
> If no uri is passed to one of the virConnectOpen-ish calls, libvirt
> attempts to autoprobe a sensible URI. Part of the current logic checks
> for getuid() > 0, and if that check is succesful, a libvirtd daemon is
> spawned. This patch
If no uri is passed to one of the virConnectOpen-ish calls, libvirt
attempts to autoprobe a sensible URI. Part of the current logic checks
for getuid() > 0, and if that check is succesful, a libvirtd daemon is
spawned. This patch replaces this check with a call to
access(LIBVIRTD_PRIV_UNIX_SOCKET,
17 matches
Mail list logo
