Mailinglist Archive: opensuse-features (542 mails)

< Previous Next >
[openFATE 307254] Use POSIX capabilities instead of suid
  • From: fate_noreply@xxxxxxx
  • Date: Wed, 1 Dec 2010 09:26:52 +0100 (CET)
  • Message-id: <feature-307254-28@xxxxxxxxxxxxxx>
Feature changed by: Ludwig Nussel (lnussel)
Feature #307254, revision 28
Title: Use POSIX capabilities instead of suid

openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger)
reject date: 2010-11-04 13:34:16
reject reason: not done
Requester: Neutral

openSUSE-11.4: Evaluation by engineering manager
Requester: Neutral

Requested by: Pascal Bleser (pbleser)
Product Manager: openfate dummy manager (openfate-manager-dummy)
Project Manager: openfate dummy manager (openfate-manager-dummy)
Engineering Manager: openfate dummy manager (openfate-manager-dummy)
Developer: (Novell)
Developer: Cristian Rodríguez (elvigia)
Developer: Cristian Rodríguez (elvigia)
Developer: Cristian Rodríguez (elvigia)
Partner organization:

Use POSIX file capabilities instead of suid processes and running e.g.
Apache as root:
+ (
+ (
+ Status: fscaps support is available at packaging level via
+ /etc/permissions. See iputils as example how to do it.

#1: Jan Engelhardt (jengelh) (2009-08-09 14:21:02)
Some tools like tar(1) do not even support recording Xattrs/ACLs (yet
people still use that for backups), and Filesystem Capabilities (not
POSIX capabilities) would not be recorded either. Such should really be
addresses first, more or less.

#2: Pascal Bleser (pbleser) (2009-08-10 01:30:22) (reply to #1)
No question, it's a mid term objective. And not exactly trivial to
solve either.
I posted this feature rather as a reminder that that enhancement
exists, and that Fedora is trying to get it implemented. Just to keep
an eye on it ;)

#3: Cristian Rodríguez (elvigia) (2010-10-05 20:45:55)
I have enabled support for file capabilities in rpm using the %caps()
macro in factory
However having it enabled in rpm is not that useful as the actual
feature has to be activated manually by the user booting with
file_caps=1 , does anyone know the reason why it isnt enabled by
default ? 

#4: Ludwig Nussel (lnussel) (2010-10-11 09:59:23)
Before we can use fscaps in packages...
1) we need a mechanism that handles fscaps similar to /etc/permissions
2) we need an rpmlint check
3) binaries need to be audited whether they are suitable for fscaps
use, just like setuid binaries

#5: Ludwig Nussel (lnussel) (2010-10-28 13:20:50)
Are we absolutely sure that 11.4 does support file capabilities by
I wonder whether to implement a runtime switchable way between
traditional suid binaries and fscaps.
Also what about run time upgrades to the new distro? In that case the
old kernel without fscaps is running but we would install binaries that
rely on fscaps. Ie the system wouldn't work properly until reboot.

#8: Cristian Rodríguez (elvigia) (2010-11-05 01:53:36) (reply to #5)
It is disabled by default.. have to boot with  file_caps=1  .. does
anyone know why is that ? 

#6: Andreas Jaeger (a_jaeger) (2010-11-04 13:35:21)
Seems to be the same idea that Fedora is doing now:

#7: Ludwig Nussel (lnussel) (2010-11-04 14:08:42) (reply to #6)
yes. my current plan is to not change attributes in the packages
though. Instead applying fscaps happens automatically via
/etc/permissions mechanism if the system supports it. That avoids the
problems Fedora sees atm with file systems that do not support fscaps.
See home:lnussel:fscaps for current state

#9: Sławomir Lach (lachu) (2010-11-07 10:17:22)
I doubt Posix Capabilities is more secure. Imagine, that program still
is runned on user privileges + some capabilties. User can debug
program, changing memory of it, etc.

#10: Sławomir Lach (lachu) (2010-11-07 10:53:15)
Maybe PolicyKit team will add support of PCaps to PKexec? In this case
any process can run process with some capabilities, but also in
different process group.

#11: Ludwig Nussel (lnussel) (2010-11-24 13:29:38)
fscaps support is now implemented in the permissions package. See ping
in package iputils as example.

openSUSE Feature:

< Previous Next >
This Thread
  • No further messages