Latest upstream release: 2.20 Current version in Fedora Rawhide: 2.17 URL: http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
Release notes for 2.20 Jan 19, 2011 * Latest kernel capabilites supported: now includes CAP_SYSLOG (patch from Sergey Senozhatsky) * $(CFLAGS) Makefile fixes from Torsten Werner * Default to installing setcap with an inheritable capability. o You can disable this feature with: make RAISE_SETFCAP=no install Release notes for 2.19 Jan 14, 2010 * Latest kernel header(s) - now include linux/securebits.h and linux/prctl.h copy * capsh o --print securebits in binary o support --drop=all o --print text usernames as well as numeric ids o add test for max lock-down state * New sys/securebits.h (from Serge) Release notes for 2.18 Dec 6, 2009 * Some documentation fixes from Mike Frysinger (getcap.8 and setcap.8) * Manual entry created for capsh.1 * Added features to capsh: o --print supplementary group list o --user=<foo> argument to set user and groups to named user o --gid=<N> set gid of current user (N is numeric) o --groups=<g1>,<g2>,... to set supplementary group list
any progress in this? I could use CAP_SYSLOG in syslog-ng please see https://bugzilla.balabit.com/show_bug.cgi?id=108
(In reply to comment #2) > any progress in this? I could use CAP_SYSLOG in syslog-ng > > please see > > https://bugzilla.balabit.com/show_bug.cgi?id=108 and the local tracking ticket: * syslog-ng: Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated) https://bugzilla.redhat.com/show_bug.cgi?id=718439
Version 2.19 builds with following specfile change (trivial): --------- @@ -65,6 +65,7 @@ %{_mandir}/man8/* /%{_lib}/security/pam_cap.so %doc doc/capability.notes License +%{_mandir}/man1/* %files devel %defattr(-,root,root,-) --------- Both versions 2.20 and 2.21 fail with the following problem: --------- ... make -C progs install make[1]: Entering directory `/builddir/build/BUILD/libcap-2.20/progs' mkdir -p -m 0755 /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin for p in getpcaps capsh getcap setcap ; do \ install -m 0755 $p /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin ; \ done /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin/setcap cap_setfcap=i /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin/setcap unable to set CAP_SETFCAP effective capability: Operation not permitted make[1]: Leaving directory `/builddir/build/BUILD/libcap-2.20/progs' make[1]: *** [install] Error 1 make: *** [install] Error 2 --------- /jpo PS - Version 2.21 libcap tarball from: http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/
Libcap homepage: * https://sites.google.com/site/fullycapable/ Release notes for libcap: * https://sites.google.com/site/fullycapable/release-notes-for-libcap Download directory: * http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/ Version 2.21 changelog: ---------- Release notes for 2.21 (Apr 28, 2011) * Introduce cap_get_bound() and cap_drop_bound() functions. also include a macro CAP_IS_SUPPORTED(cap) for capabilities * Add a manual cross link from libcap(3) to capsh(1) ---------
(In reply to comment #4) > Both versions 2.20 and 2.21 fail with the following problem: > --------- > ... > make -C progs install > make[1]: Entering directory `/builddir/build/BUILD/libcap-2.20/progs' > mkdir -p -m 0755 /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin > for p in getpcaps capsh getcap setcap ; do \ > install -m 0755 $p > /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin ; \ > done > /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin/setcap > cap_setfcap=i > /builddir/build/BUILDROOT/libcap-2.20-0.fc15.x86_64//usr/sbin/setcap > unable to set CAP_SETFCAP effective capability: Operation not permitted > make[1]: Leaving directory `/builddir/build/BUILD/libcap-2.20/progs' > make[1]: *** [install] Error 1 > make: *** [install] Error 2 > --------- Adding 'RAISE_SETFCAP=no' to the make install line allows the build to finish (note in the Make.Rules file should be read): ---------- -make install DESTDIR=${RPM_BUILD_ROOT} \ +make RAISE_SETFCAP=no install \ + DESTDIR=${RPM_BUILD_ROOT} \ ---------
Latest upstream release: 2.22 Current version in Fedora Rawhide: 2.17 URL: http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
Release notes for 2.22 * Clarified License file (with version 2 of the GPL) * Support getting/setting capabilities on large files (Patch courtesy of Mikhail Kulinich by way of Serge Hallyn). * After --chroot command, change working directory to "/". This follows a suggestion from Steve Grubb, who pointed out: http://cwe.mitre.org/data/definitions/243.html
ping
libcap-2.22-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libcap-2.22-1.fc15
libcap-2.22-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/libcap-2.22-1.fc14
Package libcap-2.22-1.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libcap-2.22-1.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libcap-2.22-1.fc14 then log in and leave karma (feedback).
libcap-2.22-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
libcap-2.22-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.