On 27/11/2017 14:44, Michal Privoznik wrote:
> On 11/27/2017 12:09 PM, Paolo Bonzini wrote:
>> On 24/11/2017 19:13, Michal Privoznik wrote:
>>> On 11/24/2017 06:18 PM, Paolo Bonzini wrote:
On 24/11/2017 18:07, Michal Privoznik wrote:
> The helper is going to be daemonized (for the same
On 11/27/2017 12:09 PM, Paolo Bonzini wrote:
> On 24/11/2017 19:13, Michal Privoznik wrote:
>> On 11/24/2017 06:18 PM, Paolo Bonzini wrote:
>>> On 24/11/2017 18:07, Michal Privoznik wrote:
The helper is going to be daemonized (for the same reason
that qemu process is) => there's no
On 27/11/2017 14:35, Michal Privoznik wrote:
>>> But can you also test _more_ permissions if you want? So if QEMU passed
>>> to the helper a file for which it has "lock" but not "ioctl" access,
>>> would it make sense for the helper to let it through? Together with the
>>> socket MAC, this
On 11/27/2017 02:29 PM, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 02:01:06PM +0100, Paolo Bonzini wrote:
>> On 27/11/2017 13:57, Daniel P. Berrange wrote:
Got it. My problem here is that ioctl permission might be too strict.
One use case for the helper is to bypass the ioctl
On Mon, Nov 27, 2017 at 02:01:06PM +0100, Paolo Bonzini wrote:
> On 27/11/2017 13:57, Daniel P. Berrange wrote:
> >> Got it. My problem here is that ioctl permission might be too strict.
> >> One use case for the helper is to bypass the ioctl permission, and only
> >> grant SCSI passthrough
On 27/11/2017 13:57, Daniel P. Berrange wrote:
>> Got it. My problem here is that ioctl permission might be too strict.
>> One use case for the helper is to bypass the ioctl permission, and only
>> grant SCSI passthrough access for the specific case of persistent
>> reservation commands. Would
On 27/11/2017 13:18, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 12:51:33PM +0100, Paolo Bonzini wrote:
>> On 27/11/2017 12:37, Daniel P. Berrange wrote:
>>> On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote:
Hm, I see what you mean now. But it would be "just" a
On Mon, Nov 27, 2017 at 01:49:41PM +0100, Paolo Bonzini wrote:
> On 27/11/2017 13:18, Daniel P. Berrange wrote:
> > On Mon, Nov 27, 2017 at 12:51:33PM +0100, Paolo Bonzini wrote:
> >> On 27/11/2017 12:37, Daniel P. Berrange wrote:
> >>> On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini
On Mon, Nov 27, 2017 at 12:51:33PM +0100, Paolo Bonzini wrote:
> On 27/11/2017 12:37, Daniel P. Berrange wrote:
> > On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote:
> >> Hm, I see what you mean now. But it would be "just" a qemu-pr-helper
> >> bug that it trusts the caller to have
On 27/11/2017 12:37, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote:
>> Hm, I see what you mean now. But it would be "just" a qemu-pr-helper
>> bug that it trusts the caller to have "ioctl" permissions on the file
>> descriptor, wouldn't it?
>>
>> And it
On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote:
> On 27/11/2017 11:59, Daniel P. Berrange wrote:
> > On Mon, Nov 27, 2017 at 11:57:56AM +0100, Paolo Bonzini wrote:
> >> On 27/11/2017 10:40, Daniel P. Berrange wrote:
> >>>
> >>> If we had one daemon per QEMU, then we would give the
On 27/11/2017 11:59, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 11:57:56AM +0100, Paolo Bonzini wrote:
>> On 27/11/2017 10:40, Daniel P. Berrange wrote:
>>>
>>> If we had one daemon per QEMU, then we would give the daemon the same
>>> MCS label as QEMU. The kernel will thus enforce this
On 24/11/2017 19:13, Michal Privoznik wrote:
> On 11/24/2017 06:18 PM, Paolo Bonzini wrote:
>> On 24/11/2017 18:07, Michal Privoznik wrote:
>>> The helper is going to be daemonized (for the same reason
>>> that qemu process is) => there's no SIGCHLD for libvirtd to receive.
>>
>> Couldn't (or
On Mon, Nov 27, 2017 at 11:57:56AM +0100, Paolo Bonzini wrote:
> On 27/11/2017 10:40, Daniel P. Berrange wrote:
> >
> > If we had one daemon per QEMU, then we would give the daemon the same
> > MCS label as QEMU. The kernel will thus enforce this label matches the
> > label on the QEMU process
On 27/11/2017 10:40, Daniel P. Berrange wrote:
>
> If we had one daemon per QEMU, then we would give the daemon the same
> MCS label as QEMU. The kernel will thus enforce this label matches the
> label on the QEMU process when it connects to the UNIX socket. The kernel
> will also validate the
On Fri, Nov 24, 2017 at 04:42:00PM +0100, Paolo Bonzini wrote:
> On 24/11/2017 15:52, Daniel P. Berrange wrote:
> >> So what has been suggested so far is:
> >>
> >>
> >>
> >>
> >>
> >>
>
> without an inner element leaves libvirtd with
> the choice of a daemon per QEMU, or
On Mon, Nov 27, 2017 at 07:27:17 +0100, Michal Privoznik wrote:
> On 11/26/2017 09:32 AM, Peter Krempa wrote:
> > On Fri, Nov 24, 2017 at 15:38:54 +0100, Michal Privoznik wrote:
> >> On 08/22/2017 06:27 PM, Paolo Bonzini wrote:
[...]
> >> However, we want to be able to turn it on/off or not
On 11/26/2017 09:32 AM, Peter Krempa wrote:
> On Fri, Nov 24, 2017 at 15:38:54 +0100, Michal Privoznik wrote:
>> On 08/22/2017 06:27 PM, Paolo Bonzini wrote:
>>> Hi all,
>>>
>>
>> Sorry for resurrecting old thread but seems like there was no agreement
>> reached.
>>
>> We don't want to expose any
On Fri, Nov 24, 2017 at 15:38:54 +0100, Michal Privoznik wrote:
> On 08/22/2017 06:27 PM, Paolo Bonzini wrote:
> > Hi all,
> >
>
> Sorry for resurrecting old thread but seems like there was no agreement
> reached.
>
> We don't want to expose any paths because the fact that PR helper is a
>
On 11/24/2017 06:18 PM, Paolo Bonzini wrote:
> On 24/11/2017 18:07, Michal Privoznik wrote:
>> On 11/24/2017 04:42 PM, Paolo Bonzini wrote:
>>> One daemon per QEMU is nicer IMO because it lets us do MCS. Of course
>>> one daemon per QEMU can only apply to system libvirtd; session must use
>>> one
On 24/11/2017 18:07, Michal Privoznik wrote:
> On 11/24/2017 04:42 PM, Paolo Bonzini wrote:
>> One daemon per QEMU is nicer IMO because it lets us do MCS. Of course
>> one daemon per QEMU can only apply to system libvirtd; session must use
>> one daemon per host.
>
> Agreed. One daemon per QEMU
On 11/24/2017 04:42 PM, Paolo Bonzini wrote:
> On 24/11/2017 15:52, Daniel P. Berrange wrote:
>>> So what has been suggested so far is:
>>>
>>>
>>>
>>>
>>>
>>>
>
> without an inner element leaves libvirtd with
> the choice of a daemon per QEMU, or a daemon per host in a
On 24/11/2017 15:52, Daniel P. Berrange wrote:
>> So what has been suggested so far is:
>>
>>
>>
>>
>>
>>
without an inner element leaves libvirtd with
the choice of a daemon per QEMU, or a daemon per host in a well-known
location. Unprivileged libvirtd would always use
On Fri, Nov 24, 2017 at 03:38:54PM +0100, Michal Privoznik wrote:
> On 08/22/2017 06:27 PM, Paolo Bonzini wrote:
> > Hi all,
> >
>
> Sorry for resurrecting old thread but seems like there was no agreement
> reached.
>
> We don't want to expose any paths because the fact that PR helper is a
>
On 08/22/2017 06:27 PM, Paolo Bonzini wrote:
> Hi all,
>
Sorry for resurrecting old thread but seems like there was no agreement
reached.
We don't want to expose any paths because the fact that PR helper is a
separate binary that uses a UNIX socket to talk to qemu is a
implementation detail of
On 04/10/2017 10:28, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 06:53:56PM +0200, Paolo Bonzini wrote:
>> On 03/10/2017 18:39, Daniel P. Berrange wrote:
>>> On Tue, Oct 03, 2017 at 06:35:03PM +0200, Paolo Bonzini wrote:
And later on we might have other ways to implement persistent
On Tue, Oct 03, 2017 at 06:53:56PM +0200, Paolo Bonzini wrote:
> On 03/10/2017 18:39, Daniel P. Berrange wrote:
> > On Tue, Oct 03, 2017 at 06:35:03PM +0200, Paolo Bonzini wrote:
> >> And later on we might have other ways to implement persistent
> >> reservations in QEMU. So while I'm not a big
On 03/10/2017 18:39, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 06:35:03PM +0200, Paolo Bonzini wrote:
>> And later on we might have other ways to implement persistent
>> reservations in QEMU. So while I'm not a big fan(*) of the
>> driver='helper' moniker, I don't think an attribute is
On Tue, Oct 03, 2017 at 06:35:03PM +0200, Paolo Bonzini wrote:
> On 03/10/2017 18:17, Daniel P. Berrange wrote:
> > On Tue, Oct 03, 2017 at 06:07:53PM +0200, Paolo Bonzini wrote:
> >> Yes, but OTOH if libvirtd starts the daemon, nobody cares about the
> >> source type, so perhaps
> >>
> >>
>
On 03/10/2017 18:17, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 06:07:53PM +0200, Paolo Bonzini wrote:
>> Yes, but OTOH if libvirtd starts the daemon, nobody cares about the
>> source type, so perhaps
>>
>>
>>
>>
>>
>> (mandatory source) vs.
>>
>>
>>
On 03/10/2017 17:59, Michal Privoznik wrote:
> Ah, this breaks my design. I guess
>
>
>
>
>
>
>
> is pure madness, isn't it?
Yes, but OTOH if libvirtd starts the daemon, nobody cares about the
source type, so perhaps
(mandatory source) vs.
On Tue, Oct 03, 2017 at 06:07:53PM +0200, Paolo Bonzini wrote:
> On 03/10/2017 17:59, Michal Privoznik wrote:
> > Ah, this breaks my design. I guess
> >
> >
> >
> >
> >
> >
> >
> > is pure madness, isn't it?
>
> Yes, but OTOH if libvirtd starts the daemon, nobody cares
On 09/10/2017 11:38 AM, Paolo Bonzini wrote:
> On 28/08/2017 13:11, Michal Privoznik wrote:
>> On 08/25/2017 12:41 AM, Paolo Bonzini wrote:
>>> On 22/08/2017 18:27, Paolo Bonzini wrote:
Hi all,
>>
>>>
>>> The XML to use the helper with a predefined socket could be:
>>>
>>>
>>>
On 11/09/2017 17:53, Daniel P. Berrange wrote:
> On Mon, Sep 11, 2017 at 05:47:28PM +0200, Paolo Bonzini wrote:
>> On 11/09/2017 17:33, Daniel P. Berrange wrote:
>>> On Mon, Sep 11, 2017 at 05:27:20PM +0200, Paolo Bonzini wrote:
On 11/09/2017 17:23, Daniel P. Berrange wrote:
>> On the
On Mon, Sep 11, 2017 at 05:47:28PM +0200, Paolo Bonzini wrote:
> On 11/09/2017 17:33, Daniel P. Berrange wrote:
> > On Mon, Sep 11, 2017 at 05:27:20PM +0200, Paolo Bonzini wrote:
> >> On 11/09/2017 17:23, Daniel P. Berrange wrote:
> On the other hand, the daemon has CAP_SYS_RAWIO and
On 11/09/2017 17:33, Daniel P. Berrange wrote:
> On Mon, Sep 11, 2017 at 05:27:20PM +0200, Paolo Bonzini wrote:
>> On 11/09/2017 17:23, Daniel P. Berrange wrote:
On the other hand, the daemon has CAP_SYS_RAWIO and CAP_SYS_ADMIN, so if
you get memory corruption all bets are probably off
On 11/09/2017 17:23, Daniel P. Berrange wrote:
>> On the other hand, the daemon has CAP_SYS_RAWIO and CAP_SYS_ADMIN, so if
>> you get memory corruption all bets are probably off anyway.
> That's where the benefit of strict selinux labelling comes in. If we had
> strict labelling of the individual
On Mon, Sep 11, 2017 at 05:20:10PM +0200, Paolo Bonzini wrote:
> On 11/09/2017 16:32, Daniel P. Berrange wrote:
> >> This is already handled via SCM_RIGHTS and is part of the design of the
> >> helper daemon. QEMU cannot even open mpath devices which are not
> >> accessible according to its
On Mon, Sep 11, 2017 at 05:27:20PM +0200, Paolo Bonzini wrote:
> On 11/09/2017 17:23, Daniel P. Berrange wrote:
> >> On the other hand, the daemon has CAP_SYS_RAWIO and CAP_SYS_ADMIN, so if
> >> you get memory corruption all bets are probably off anyway.
> > That's where the benefit of strict
On 11/09/2017 16:32, Daniel P. Berrange wrote:
>> This is already handled via SCM_RIGHTS and is part of the design of the
>> helper daemon. QEMU cannot even open mpath devices which are not
>> accessible according to its SELinux category or device cgroup.
>
> Ah so the daemon relies on the fact
On Mon, Sep 11, 2017 at 04:23:27PM +0200, Paolo Bonzini wrote:
> On 11/09/2017 14:09, Daniel P. Berrange wrote:
> > On Mon, Sep 11, 2017 at 01:44:59PM +0200, Paolo Bonzini wrote:
> >> On 11/09/2017 12:46, Daniel P. Berrange wrote:
> So the helper is a bit different from QEMU with respect to
On 11/09/2017 14:09, Daniel P. Berrange wrote:
> On Mon, Sep 11, 2017 at 01:44:59PM +0200, Paolo Bonzini wrote:
>> On 11/09/2017 12:46, Daniel P. Berrange wrote:
So the helper is a bit different from QEMU with respect to both SELinux
MCS labeling and the devices cgroup. Access
On Mon, Sep 11, 2017 at 01:44:59PM +0200, Paolo Bonzini wrote:
> On 11/09/2017 12:46, Daniel P. Berrange wrote:
> >> So the helper is a bit different from QEMU with respect to both SELinux
> >> MCS labeling and the devices cgroup. Access limitation comes from only
> >> ever operating on devices
On 11/09/2017 12:46, Daniel P. Berrange wrote:
>> So the helper is a bit different from QEMU with respect to both SELinux
>> MCS labeling and the devices cgroup. Access limitation comes from only
>> ever operating on devices that have been passed on the socket. SELinux
>> MCS could be used so
On Sun, Sep 10, 2017 at 11:52:24AM +0200, Paolo Bonzini wrote:
> On 29/08/2017 14:41, Daniel P. Berrange wrote:
> > On Tue, Aug 22, 2017 at 06:27:40PM +0200, Paolo Bonzini wrote:
> >> Hi all,
> >>
> >> I am adding a new daemon to QEMU, that QEMU can connect to in order to
> >> issue persistent
On 29/08/2017 14:41, Daniel P. Berrange wrote:
> On Tue, Aug 22, 2017 at 06:27:40PM +0200, Paolo Bonzini wrote:
>> Hi all,
>>
>> I am adding a new daemon to QEMU, that QEMU can connect to in order to
>> issue persistent reservation commands.
>
> Can you elaborate on what this daemon does ?
>
>
On 10/09/2017 11:38, Paolo Bonzini wrote:
> The daemon can then be
> placed in the same devices cgroup and SELinux MCS category as QEMU.
At least regarding the devices cgroup, this is wrong, sorry (the socket
can be given an MCS category to restrict who connects to it, but not the
daemon). More
On 28/08/2017 13:11, Michal Privoznik wrote:
> On 08/25/2017 12:41 AM, Paolo Bonzini wrote:
>> On 22/08/2017 18:27, Paolo Bonzini wrote:
>>> Hi all,
>
> Hey, sorry for late reply. I was enjoying my PTO by not reading e-mails :-)
Me too!
>>>
>>> I am adding a new daemon to QEMU, that QEMU can
On Tue, Aug 22, 2017 at 06:27:40PM +0200, Paolo Bonzini wrote:
> Hi all,
>
> I am adding a new daemon to QEMU, that QEMU can connect to in order to
> issue persistent reservation commands.
Can you elaborate on what this daemon does ?
IIUC, by 'persistent reservation' you are referring to SCSI
On 08/25/2017 12:41 AM, Paolo Bonzini wrote:
> On 22/08/2017 18:27, Paolo Bonzini wrote:
>> Hi all,
Hey, sorry for late reply. I was enjoying my PTO by not reading e-mails :-)
>>
>> I am adding a new daemon to QEMU, that QEMU can connect to in order to
>> issue persistent reservation commands.
On 22/08/2017 18:27, Paolo Bonzini wrote:
> Hi all,
>
> I am adding a new daemon to QEMU, that QEMU can connect to in order to
> issue persistent reservation commands.
>
> The daemon can only issue the commands on file descriptor that QEMU
> already has. In addition normal users shouldn't have
Hi all,
I am adding a new daemon to QEMU, that QEMU can connect to in order to
issue persistent reservation commands.
The daemon can only issue the commands on file descriptor that QEMU
already has. In addition normal users shouldn't have access to the
daemon's Unix socket in /run, so the
52 matches
Mail list logo
