[libvirt] [sandbox] Weird apparmor problems

[Jamie Strandboge]

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=d0d4b8ad76d3e8a859ee90701a21a3f003a22c1f
> 
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=29ea8a9b64aac60251d283f74d57690e4edb5a6b

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151111/10e82ab1/attachment-0001.sig>