(In reply to Steve Grubb from comment #0)
> Description of problem:
> Libcap-ng-0.8.2 does better error detection of some problems that were
> previously hidden. A patched version of libcap-ng is now emitting warnings
> when it sees a problem in the use of the API.
> 
> Currently there is a call to capng_apply which is apparently clearing the
> bounding set. However, libvirt doesn't have CAP_SETPCAP which means that it
> cannot change the bounding set. Switching from 
> capng_apply(CAPNG_SELECT_BOTH);   to   capng_apply(CAPNG_SELECT_CAPS);
> should fix the issue. But it doesn't clear the bounding set. On the
> otherhand, the bounding set wasn't getting cleared in the first place. If it
> needed to be cleared, it should be done earlier in the process when libvirt
> had full capabilities.

Looking at the two place where libvirt uses SELECT_BOTH, we should have full caps in both cases.

Can you give more details on the scenario in which you're triggering the warning in libvirt

The error message is because it is falling into the else branch here:
https://github.com/stevegrubb/libcap-ng/blob/master/src/cap-ng.c#L729

Fedora is patched to not return the -4 and to log that it failed.

What libvirt functionality are you using to trigger this ?

This is in the logs after system boot. If I stop and start libvirt, it picks up 2 new warnings.

We have some code to conditionally preserve  CAP_SETPCAP in case where we expect to need it

https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virutil.c#L1203

The later code which actually does the     capng_apply(CAPNG_SELECT_BOUNDS); call is unconditional though:

https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virutil.c#L1270


IOW, it looks like we were silently just expecting the capng_apply() to fail in the cases where we didn't keep CAP_SETPCAP

This previous harmless failure now triggers the warning message, so guess we should make the call to capng_apply conditional on whether we really need it.

Well, at least whether or not to include the BOUNDING_SET should be conditional. You can still change caps in some cases if it's to lower them. I apologize for the behavior change, but some people really needed a hard error returned because they needed to know the bounding set was still wide open even though it was supposedly cleared.

*** Bug 1925094 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Could somebody clarify is this issue is supposed to be resolved in F34? And if not, is it just a warning that can be ignored?

The bug is also reported as bug 1940791.

Still a thing in F34. After upgrade to F34 I am seeing this:
$ sudo systemctl status libvirtd
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2021-05-10 22:02:04 CEST; 4s ago
TriggeredBy: ● libvirtd-admin.socket
             ● libvirtd-ro.socket
             ● libvirtd.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
   Main PID: 259911 (libvirtd)
      Tasks: 21 (limit: 32768)
     Memory: 40.1M
        CPU: 399ms
     CGroup: /system.slice/libvirtd.service
             ├─  1771 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
             ├─  1772 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
             └─259911 /usr/sbin/libvirtd --timeout 120

May 10 22:02:04 example.com systemd[1]: Starting Virtualization daemon...
May 10 22:02:04 example.com systemd[1]: Started Virtualization daemon.
May 10 22:02:04 example.com libvirtd[259931]: libcap-ng used by "/usr/sbin/libvirtd" failed due to not having CAP_SETPCAP in capng_apply
May 10 22:02:04 example.com libvirtd[259932]: libcap-ng used by "/usr/sbin/libvirtd" failed due to not having CAP_SETPCAP in capng_apply
May 10 22:02:04 example.com dnsmasq[1771]: read /etc/hosts - 23 addresses
May 10 22:02:04 example.com dnsmasq[1771]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
May 10 22:02:04 example.com dnsmasq-dhcp[1771]: read /var/lib/libvirt/dnsmasq/default.hostsfile


$ rpm -q libvirt-daemon libcap-ng
libvirt-daemon-7.0.0-4.fc34.x86_64
libcap-ng-0.8.2-4.fc34.x86_64

According to https://bugzilla.redhat.com/show_bug.cgi?id=1952715#c4, a rebuild should be enough

(In reply to Timothée Ravier from comment #11)
> According to https://bugzilla.redhat.com/show_bug.cgi?id=1952715#c4, a
> rebuild should be enough

I looked into that. The problem there is in the service file.

Just confirming I'm observing the same behaviour:

 sudo systemctl status libvirtd.service
○ libvirtd.service - Virtualization daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Fri 2021-05-14 09:28:49 BST; 9min ago
TriggeredBy: ● libvirtd-ro.socket
             ● libvirtd-admin.socket
             ● libvirtd.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
    Process: 45798 ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS (code=exited, status=0/SUCCESS)
   Main PID: 45798 (code=exited, status=0/SUCCESS)
      Tasks: 2 (limit: 32768)
     Memory: 30.7M
        CPU: 370ms
     CGroup: /system.slice/libvirtd.service
             ├─1218 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
             └─1219 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper

May 14 09:26:49 mun1n systemd[1]: Starting Virtualization daemon...
May 14 09:26:49 mun1n systemd[1]: Started Virtualization daemon.
May 14 09:26:49 mun1n libvirtd[45821]: libcap-ng used by "/usr/sbin/libvirtd" failed due to not having CAP_SETPCAP in capng_apply
May 14 09:26:49 mun1n libvirtd[45822]: libcap-ng used by "/usr/sbin/libvirtd" failed due to not having CAP_SETPCAP in capng_apply
May 14 09:26:49 mun1n dnsmasq[1218]: read /etc/hosts - 2 addresses
May 14 09:26:49 mun1n dnsmasq[1218]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
May 14 09:26:49 mun1n dnsmasq-dhcp[1218]: read /var/lib/libvirt/dnsmasq/default.hostsfile
May 14 09:28:49 mun1n systemd[1]: libvirtd.service: Deactivated successfully.
May 14 09:28:49 mun1n systemd[1]: libvirtd.service: Unit process 1218 (dnsmasq) remains running after unit stopped.
May 14 09:28:49 mun1n systemd[1]: libvirtd.service: Unit process 1219 (dnsmasq) remains running after unit stopped.
$ rpm -q libvirt-daemon libcap-ng
libvirt-daemon-7.0.0-4.fc34.x86_64
libcap-ng-0.8.2-4.fc34.x86_64
$

*** Bug 1940791 has been marked as a duplicate of this bug. ***

Time appropriate greetings,

I'd like to confirm that I see this issue in F34 not with libvirt but with `/usr/sbin/mount.cifs`. The exact error showing up in journald is:

"Mai 20 20:42:29 t14s mount.cifs[11933]: libcap-ng used by "/usr/sbin/mount.cifs" failed due to not having CAP_SETPCAP in capng_apply"

~~~
$ rpm -q cifs-utils libcap-ng
cifs-utils-6.11-3.fc34.x86_64
libcap-ng-0.8.2-4.fc34.x86_64
~~~

Regards,  
Joerg

(In reply to Joerg K from comment #15)
> Time appropriate greetings,
> 
> I'd like to confirm that I see this issue in F34 not with libvirt but with
> `/usr/sbin/mount.cifs`. The exact error showing up in journald is:
> 
> "Mai 20 20:42:29 t14s mount.cifs[11933]: libcap-ng used by
> "/usr/sbin/mount.cifs" failed due to not having CAP_SETPCAP in capng_apply"
> 
> ~~~
> $ rpm -q cifs-utils libcap-ng
> cifs-utils-6.11-3.fc34.x86_64
> libcap-ng-0.8.2-4.fc34.x86_64
> ~~~


That should be reported against the cifs-utils package. The issue is a case by case fix to the program being reported. The fix can be as simple as changing the capng_apply from SELECT_BOTH to SELECT_CAPS.

(In reply to Steve Grubb from comment #16)
> That should be reported against the cifs-utils package. The issue is a case
> by case fix to the program being reported. The fix can be as simple as
> changing the capng_apply from SELECT_BOTH to SELECT_CAPS.

Thanks for letting me know. I'll report it against the cifs-utils package.

clean flashed Fedro 34. I'm having this same issue.

"libcap-ng used by "/usr/sbin/libvirtd" failed due to not having CAP_SETPCAP in capng_apply"

Hope this issue solve soon...

Is there a test package available to fix this?

mount.cifs[915619]: libcap-ng used by "/usr/sbin/mount.cifs" failed due to not having CAP_SETPCAP in capng_apply

rpm -q cifs-utils libcap-ng
cifs-utils-6.11-3.fc34.x86_64
libcap-ng-0.8.2-4.fc34.x86_64

D'oh! I completely missed this bug and analysis here. I've sent a patch because of a RHEL variant of this bug:  bug 1949388

https://listman.redhat.com/archives/libvir-list/2021-June/msg00744.html

Merged upstream as:

438b50dda8 virSetUIDGIDWithCaps: Don't drop CAP_SETPCAP right away

v7.5.0-rc1-4-g438b50dda8

FEDORA-2021-6679746a3d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6679746a3d

FEDORA-2021-6679746a3d has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6679746a3d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6679746a3d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-bc6ad65da0 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-bc6ad65da0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-bc6ad65da0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-bc6ad65da0 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.