On Fri, Apr 12, 2019 at 03:54:26PM +0100, Daniel P. Berrangé wrote:
On Fri, Apr 12, 2019 at 03:32:21PM +0200, Martin Kletzander wrote:
This does not cause a problem in usual scenarios thanks to us allowing
CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
an issue
On Fri, Apr 12, 2019 at 03:32:21PM +0200, Martin Kletzander wrote:
> This does not cause a problem in usual scenarios thanks to us allowing
> CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
> an issue because the directory is created with mkdtemp(3) which explicitly
On Fri, Apr 12, 2019 at 02:45:32PM +0100, Daniel P. Berrangé wrote:
On Fri, Apr 12, 2019 at 03:32:21PM +0200, Martin Kletzander wrote:
This does not cause a problem in usual scenarios thanks to us allowing
CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
an issue
On Fri, Apr 12, 2019 at 02:45:32PM +0100, Daniel P. Berrangé wrote:
On Fri, Apr 12, 2019 at 03:32:21PM +0200, Martin Kletzander wrote:
This does not cause a problem in usual scenarios thanks to us allowing
CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
an issue
On Fri, Apr 12, 2019 at 03:32:21PM +0200, Martin Kletzander wrote:
> This does not cause a problem in usual scenarios thanks to us allowing
> CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
> an issue because the directory is created with mkdtemp(3) which explicitly
This does not cause a problem in usual scenarios thanks to us allowing
CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
an issue because the directory is created with mkdtemp(3) which explicitly
creates that with 0700 permissions and qemu running as non-root cannot
