On 10/30/2015 08:27 AM, Cedric Bosdonnat wrote:
On Fri, 2015-10-30 at 09:15 +0900, Daniel P. Berrange wrote:
> So, yes, it is normal for libvirt_lxc to access /dev/ptmx to create
> a new master PTY and to read/write to /dev/pts/NN associated with
> the file descriptor retrieved from /dev/ptmx.
After some more debugging and help from jjohansen, the problem happens
to be this commit:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=d0d4b8ad76d3e8a859ee9070...
This commit isn't the actual issue. It is the logic in this commit combined
with:
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=29ea8a9b64aac60251d2...
In the original commit, presumably only 'deny / w,' would have been added, but
with the second commit, this turns into 'deny /** w,'.
When having the not-so-silly idea to mount the host / readonly in a
qemu
guest (like what virt-sandbox is doing), we are adding a "deny /** w"
rule taking precedence over all rules giving write access to files
inside that path.
Would there be a clean solution for that problem? I can already teach
virt-sandbox to add the host / mount only if there is nothing else to be
mounted as /, but that wouldn't cover all cases.
There is nothing that can be done with additional rules if the 'deny /**
w,' is
being added because deny rules always take precedence over other rules. The only
course of action is to rework the logic introduced in
29ea8a9b64aac60251d283f74d57690e4edb5a6b. One option might be to revert it and
then add the glob rule conditionally on if it is a 9p filesystem. I'm not sure
if this is even valid for 9p filesystems though.
--
Jamie Strandboge
http://www.ubuntu.com/