Hello,
A new version of libcap-ng is going to be released next week. Normally this isn't newsworthy, nor is this a soname version bump. But it is important to let the broader community know something about it. The behaviour of capng_apply is changing slightly.
In the past, capng_apply would silently eat errors when the bounding set could not be changed. In order to change the bounding set, you have to have CAP_SETPCAP. A developer reported an issue in github where their project needed to know that capng_apply was completely successful changing the bounding set. Meaning that they need an error returned. I didn't think too much of it and made the change.
Then one day I noticed that I could not update a package against Fedora's git or push a change. Looking into this, I found gnome-keyring was not working. [1] I dug into the source code and found that it was trying to change the bounding set when it had partial capabilities. The fix is to simply verify that you have CAP_SETPCAP before attempting this.
I don't know of any other software that is affected. But I wanted to give everyone a heads up before I push it out. I always dogfood libraries I work on, so maybe this is the only issue.
Eventually libcap-ng needs to get pushed over to F33 because there is a problem with ambient capailities that the new release fixes. And speaking of ambient capabilities, the new version of libcap-ng contains a new library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app to drop ambient capabilities leaving the other capabilities intact. All the work is done in the constructor, so no function calls are needed.
Best Regards, -Steve
Hello,
The new libcap-ng has been built into rawhide.
Cheers, -Steve
On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote:
A new version of libcap-ng is going to be released next week. Normally this isn't newsworthy, nor is this a soname version bump. But it is important to let the broader community know something about it. The behaviour of capng_apply is changing slightly.
In the past, capng_apply would silently eat errors when the bounding set could not be changed. In order to change the bounding set, you have to have
CAP_SETPCAP. A developer reported an issue in github where their project needed to know that capng_apply was completely successful changing the bounding set. Meaning that they need an error returned. I didn't think too much of it and made the change.
Then one day I noticed that I could not update a package against Fedora's git or push a change. Looking into this, I found gnome-keyring was not working. [1] I dug into the source code and found that it was trying to change the bounding set when it had partial capabilities. The fix is to simply verify that you have CAP_SETPCAP before attempting this.
I don't know of any other software that is affected. But I wanted to give everyone a heads up before I push it out. I always dogfood libraries I work on, so maybe this is the only issue.
Eventually libcap-ng needs to get pushed over to F33 because there is a problem with ambient capailities that the new release fixes. And speaking of ambient capabilities, the new version of libcap-ng contains a new library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app to drop ambient capabilities leaving the other capabilities intact. All the work is done in the constructor, so no function calls are needed.
Best Regards, -Steve
1 - https://bugzilla.redhat.com/show_bug.cgi?id=1888978
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.or g
On Wed, 2020-11-18 at 14:32 -0500, Steve Grubb wrote:
On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote:
A new version of libcap-ng is going to be released next week. Normally this isn't newsworthy, nor is this a soname version bump. But it is important to let the broader community know something about it. The behaviour of capng_apply is changing slightly.
In the past, capng_apply would silently eat errors when the bounding set could not be changed. In order to change the bounding set, you have to have
CAP_SETPCAP. A developer reported an issue in github where their project needed to know that capng_apply was completely successful changing the bounding set. Meaning that they need an error returned. I didn't think too much of it and made the change.
Then one day I noticed that I could not update a package against Fedora's git or push a change. Looking into this, I found gnome-keyring was not working. [1] I dug into the source code and found that it was trying to change the bounding set when it had partial capabilities. The fix is to simply verify that you have CAP_SETPCAP before attempting this.
I don't know of any other software that is affected. But I wanted to give everyone a heads up before I push it out. I always dogfood libraries I work on, so maybe this is the only issue.
Eventually libcap-ng needs to get pushed over to F33 because there is a problem with ambient capailities that the new release fixes. And speaking of ambient capabilities, the new version of libcap-ng contains a new library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app to drop ambient capabilities leaving the other capabilities intact. All the work is done in the constructor, so no function calls are needed.
Hello,
The new libcap-ng has been built into rawhide.
...and it does break gnome-keyring, and it also breaks cifs-utils (so you can't mount CIFS/SMB shares), as per this upstream bug report:
https://github.com/stevegrubb/libcap-ng/issues/21
whose reporter also noted what looks like a valid problem in your gnome-keyring fix.
Was it really necessary to build this when you *knew* a major package did not work with it? Did you talk to the Workstation folks about getting the patch applied to gnome-keyring?
On Thursday, November 19, 2020 8:32:38 PM EST Adam Williamson wrote:
On Wed, 2020-11-18 at 14:32 -0500, Steve Grubb wrote:
On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote: The new libcap-ng has been built into rawhide.
...and it does break gnome-keyring, and it also breaks cifs-utils (so you can't mount CIFS/SMB shares), as per this upstream bug report:
OK. I also see something about VPN openconnect. I'm hoping that's all the major pieces.
whose reporter also noted what looks like a valid problem in your gnome-keyring fix.
For other distributions, yes. Worked fine on Fedora. A fixed pull request has positive comments from the person spotting the issue on another distribution.
Was it really necessary to build this when you *knew* a major package did not work with it? Did you talk to the Workstation folks about getting the patch applied to gnome-keyring?
A new package has been pushed that blocks reporting error codes for changing bounding sets. If this checks good, I think I can use that refactored code to syslog which programs are not using capabilities correctly. But at some point in the future, we need to allow real error codes again.
-Steve
-
Adam Williamson -
Steve Grubb