[libvirt] [PATCH v2] util: netdevbridge: fall back to ioctl from sysfs

[Christian Ehrhardt]

On Sun, Nov 25, 2018 at 10:01 PM Laine Stump <laine at laine.org> wrote:

> On 11/23/18 1:42 AM, Christian Ehrhardt wrote:
>
>
>
> On Tue, Nov 20, 2018 at 1:26 PM Daniel P. Berrangé <berrange at redhat.com>
> wrote:
>
>> On Tue, Nov 20, 2018 at 01:25:46PM +0100, Christian Ehrhardt wrote:
>> > There are certain cases e.g. containers where the sysfs path might
>> > exists, but might fail. Unfortunately the exact restrictions are only
>> > known to libvirt when trying to write to it so we need to try it.
>> >
>> > But in case it fails there is no need to fully abort, in those cases try
>> > to fall back to the older ioctl interface which can still work.
>> >
>> > That makes setting up a bridge in unprivileged LXD containers work.
>> >
>> > Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802906
>> >
>> > Signed-off-by: Christian Ehrhardt <christian.ehrhardt at canonical.com>
>> > Reported-by: Brian Candler <b.candler at pobox.com>
>> > ---
>> >  src/util/virnetdevbridge.c | 48 +++++++++++++++++++++-----------------
>> >  1 file changed, 26 insertions(+), 22 deletions(-)
>>
>> Reviewed-by: Daniel P. Berrangé <berrange at redhat.com>
>>
>
> Thanks for the review Daniel!
>
> Brian (on CC) also tested a Ubuntu build with the fix applied and it
> worked for him in unprivileged containers.
>
> There was no other feedback in the last three days.
> But this is no area I feel entitled to push the change on my own,
> therefore I wanted to ping on this - ping
>
>
> As long as you have commit privileges, feel free to push once there is a
> Reviewed-by: (unless we are in freeze).
>
 I wanted to be better safe than sorry, thanks for the confirmation.

> 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.
>
> Ack to the can-of-worms being the reason :-)
Thanks !

... pushed to master now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20181126/499e1787/attachment-0001.htm>