Displaying 4 results from an estimated 4 matches for "in_egroup_p".
2020 Aug 30
1
Re: plug pre-created tap devices to libvirt guests
...then be able to open it and give it to QEMU
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/tun.c#n586
>
> ((uid_valid(tun->owner) && !uid_eq(cred->euid, tun->owner)) ||
> (gid_valid(tun->group) && !in_egroup_p(tun->group))) &&
> !ns_capable(net->user_ns, CAP_NET_ADMIN);
>
>
> This is called by the TUNSETIFF code.
>
> AFAICT, that means if you fchown(tapfd, uid, gid), to the uid+gid of
> libvirtd, it should not require CAP_NET_ADMIN.
>
> Regards,
>...
2020 Jun 30
1
Re: plug pre-created tap devices to libvirt guests
On Tue, Jun 30, 2020 at 12:59:03PM +0200, Miguel Duarte de Mora Barroso wrote:
> On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump@redhat.com> wrote:
> >
> > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote:
> > > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote:
> > >> Hi all,
> > >>
> > >> I'm aware
2011 Aug 12
11
[net-next RFC PATCH 0/7] multiqueue support for tun/tap
As multi-queue nics were commonly used for high-end servers,
current single queue based tap can not satisfy the
requirement of scaling guest network performance as the
numbers of vcpus increase. So the following series
implements multiple queue support in tun/tap.
In order to take advantages of this, a multi-queue capable
driver and qemu were also needed. I just rebase the latest
version of
2011 Aug 12
11
[net-next RFC PATCH 0/7] multiqueue support for tun/tap
As multi-queue nics were commonly used for high-end servers,
current single queue based tap can not satisfy the
requirement of scaling guest network performance as the
numbers of vcpus increase. So the following series
implements multiple queue support in tun/tap.
In order to take advantages of this, a multi-queue capable
driver and qemu were also needed. I just rebase the latest
version of