<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 25, 2018 at 10:01 PM Laine Stump <<a href="mailto:laine@laine.org">laine@laine.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-4292826083603688288moz-cite-prefix">On 11/23/18 1:42 AM, Christian Ehrhardt
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Nov 20, 2018 at 1:26 PM Daniel P.
Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue,
Nov 20, 2018 at 01:25:46PM +0100, Christian Ehrhardt wrote:<br>
> There are certain cases e.g. containers where the sysfs
path might<br>
> exists, but might fail. Unfortunately the exact
restrictions are only<br>
> known to libvirt when trying to write to it so we need
to try it.<br>
> <br>
> But in case it fails there is no need to fully abort,
in those cases try<br>
> to fall back to the older ioctl interface which can
still work.<br>
> <br>
> That makes setting up a bridge in unprivileged LXD
containers work.<br>
> <br>
> Fixes: <a href="https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802906" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802906</a><br>
> <br>
> Signed-off-by: Christian Ehrhardt <<a href="mailto:christian.ehrhardt@canonical.com" target="_blank">christian.ehrhardt@canonical.com</a>><br>
> Reported-by: Brian Candler <<a href="mailto:b.candler@pobox.com" target="_blank">b.candler@pobox.com</a>><br>
> ---<br>
> src/util/virnetdevbridge.c | 48
+++++++++++++++++++++-----------------<br>
> 1 file changed, 26 insertions(+), 22 deletions(-)<br>
<br>
Reviewed-by: Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
</blockquote>
<div><br>
</div>
<div>Thanks for the review Daniel!</div>
<div><br>
</div>
<div>Brian (on CC) also tested a Ubuntu build with the fix
applied and it worked for him in unprivileged containers.</div>
<div><br>
</div>
<div>There was no other feedback in the last three days.</div>
<div>But this is no area I feel entitled to push the change on
my own, therefore I wanted to ping on this - ping</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>As long as you have commit privileges, feel free to push once
there is a Reviewed-by: (unless we are in freeze).</p></div></blockquote><div> I wanted to be better safe than sorry, thanks for the confirmation.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>
</p>
<p>If it makes you feel any more confident about pushing - I had
personally expressed misgivings about this patch in IRC to Dan
because on first read it sounded like we might be exploiting a
security flaw in LXC to modify networking when it shouldn't
actually be allowed, but he convinced me that the situation isn't
that "bridge and tap device management via sysfs is blocked
because it should be, and ioctls are accidentally left enabled
when they should have been disabled", but rather that "bridge/tap
device management is acceptable in this situation, but sysfs is a
huge can of worms that can only be made read-only on a global
basis (and *must* be made read-only due to all the other things
that shouldn't be allowed in this case)". Based on that, I'm okay
with the patch as well.<br>
</p>
<p></p></div></blockquote><div>Ack to the can-of-worms being the reason :-)</div><div>Thanks !</div><div><br></div><div>... pushed to master now</div></div></div>