[gentoo-dev] eclass for handling of file-based capabilities

[gentoo-dev] eclass for handling of file-based capabilities

[Constanze Hausner]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hello,

last GSoC I developed an eclass for the handling of file-based
capabilities [1]. One should be able to set file-caps for the binary from
the src_install phase. The eclass handles the setting of the caps and
also applies a fallback file-mode, if the caps-setting goes wrong.

I would be happy, if you guys and gals could take a look at it, 
and review it :).

It uses a new global use-flag (filecaps) so it wouldn't collide with
the caps use-flag and the corresponding old handling of file-caps.

The git repository, which also includes a manpage and some tests for the eclass,
is available here [2]. 
I'm going to update the eclass with your patches there.

Cheers,
Constanze

[1] http://www.friedhoff.org/posixfilecaps.html
[2] https://github.com/constanze/GSoC2010_Gentoo_Capabilities

[-- Attachment #2: fcaps.eclass --]
[-- Type: text/plain, Size: 2666 bytes --]

# Copyright 2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: fcaps.eclass
# @MAINTAINER: Constanze Hausner <constanze@gentoo.org>
# @BLURB: function to set POSIX file-based capabilities
# @DESCRIPTION:
# This eclass provides a function to set file-based capabilities on binaries.
# Due to probable capability-loss on moving or copying, this happens in
# pkg_postinst-phase (at least for now).

IUSE="filecaps"
DEPEND="filecaps? ( sys-libs/libcap )"

# @FUNCTION: fcaps 
# @USAGE: fcaps {uid:gid} {file-mode} {cap1[,cap2,...]} {file}
# @RETURN: 0 if all okay; non-zero if failure and fallback
# @DESCRIPTION:
# fcaps sets the specified capabilities in the effective and permitted set of
# the given file. In case of failure fcaps sets the given file-mode.
fcaps() {
	debug-print-function ${FUNCNAME} "$@"
	debug-print "${FUNCNAME}: Trying to set capabilities for ${4}"
	local uid_gid=$1
	local perms=$2
	export fallbackFileMode=$perms
	local capset=$3
	local path=$4
	if [ $# -eq 5 ]; then
		local set_mode=$5
	else
		debug-print "${FUNCNAME}: no set-mode provided, setting it to ep"
		#if there is no set_mode provided, it is set to true
		local set_mode=1
	fi

	#set owner/group
	debug-print "${FUNCNAME}: setting owner and group to ${uid_gid}"
	chown $uid_gid $path
	if [ $? -ne 0 ]; then
		eerror "chown "$uid_gid" "$path" failed."
		return 2
	fi

	#set file-mode including suid
	debug-print "${FUNCNAME}: setting file-mode ${perms}, including suid"
	chmod $perms $path
	if [ $? -ne 0 ]; then
		eerror "chmod "$perms" "$path" failed."
		return 3
	fi

	#if filecaps is not enabled all is done
	use !filecaps && return 0

	#if libcap is not installed caps cannot be set
	if [ ! -f "/sbin/setcap" ]; then
		debug-print "${FUNCNAME}: libcap not installed, could not set caps"
		return 4
	fi

	#Check for set mode
	if [ $set_mode -eq 1 ]; then
		debug-print "${FUNCNAME}: set-mode = ep"
		local sets="=ep"
	else
		debug-print "${FUNCNAME}: set-mode = ei"
		local sets="=ei"
	fi

	#set the capability
	debug-print "${FUNCNAME}: setting capabilities"
	setcap "$capset""$sets" "$path" &> /dev/null

	#check if the capabilitiy got set correctly
	debug-print "${FUNCNAME}: checking capabilities"
	setcap -v "$capset""$sets" "$path" &> /dev/null

	local res=$?

	#if caps could be set, remove suid-bit
	if [ $res -eq 0 ]; then
		debug-print "${FUNCNAME}: caps were set, removing suid-bit"
		chmod -s $path
	else
		debug-print "${FUNCNAME}: caps could not be set"
		ewarn "setcap "$capset" "$path" failed."
		ewarn "Check your kernel and filesystem."
		ewarn "Fallback file-mode was set."
	fi

	return $res
}

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

On Sat, 5 Mar 2011 14:24:22 +0100
Constanze Hausner <constanze@gentoo.org> wrote:
> It uses a new global use-flag (filecaps) so it wouldn't collide with
> the caps use-flag and the corresponding old handling of file-caps.

You're requiring special package manager behaviour if that flag is set?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Constanze Hausner]

On 17:15 Sat 05 Mar     , Ciaran McCreesh wrote:
> On Sat, 5 Mar 2011 14:24:22 +0100
> Constanze Hausner <constanze@gentoo.org> wrote:
> > It uses a new global use-flag (filecaps) so it wouldn't collide with
> > the caps use-flag and the corresponding old handling of file-caps.
> 
> You're requiring special package manager behaviour if that flag is set?

Hi Ciaran,

I'm requiring, that the package manager preserves the xattrs, when
stripping the binary and when moving it from the sandbox to the live-fs.

I wrote a patch for portage, which I already sent to zmedico for
reviewal.

I hope I understood your question correctly :).

Cheers,
Constanze

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On Sat, 5 Mar 2011 18:41:46 +0100
Constanze Hausner <constanze@gentoo.org> wrote:
> > You're requiring special package manager behaviour if that flag is
> > set?
> 
> I'm requiring, that the package manager preserves the xattrs, when
> stripping the binary and when moving it from the sandbox to the
> live-fs.

Currently we've got wording in PMS forbidding anything from relying
upon xattrs being preserved correctly, since that's what Portage did
when we wrote it. So if you're looking to change that, you'll need to
EAPI control it.

But it's not as simple as just requiring attributes to be preserved in
future EAPIs, since:

* some xattrs are fs specific

* some xattrs (selinux?) can't be copied

* some filesystems don't support xattrs at all, and the package manager
  needs to support installing to them, even if the user is building on
  a filesystem that does support it

* tar and xattrs is a massive problem, so how do binaries work?

I think it'd help if you provided a description of how all the above
(plus the other issues that I've forgotten about) can be handled.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Constanze Hausner]

On 17:44 Sat 05 Mar     , Ciaran McCreesh wrote:
> On Sat, 5 Mar 2011 18:41:46 +0100
> Constanze Hausner <constanze@gentoo.org> wrote:
> > > You're requiring special package manager behaviour if that flag is
> > > set?
> > 
> > I'm requiring, that the package manager preserves the xattrs, when
> > stripping the binary and when moving it from the sandbox to the
> > live-fs.
> 
> Currently we've got wording in PMS forbidding anything from relying
> upon xattrs being preserved correctly, since that's what Portage did
> when we wrote it. So if you're looking to change that, you'll need to
> EAPI control it.
Yes, there would be the need for a new EAPI, if the caps should be set
from src_install and therefore need to be preserved by the PMS.
As long as there is no such garantee one could use the eclass to set the
caps from pkg_postinst. I know it's really ugly, but it would be a
start. Otherwise we will never be able to use caps.

> But it's not as simple as just requiring attributes to be preserved in
> future EAPIs, since:
> 
> * some xattrs are fs specific
> 
> * some xattrs (selinux?) can't be copied
I said something different than I thought, sorry. I only thought of the
caps and not other kinds of xattr, as I only require caps to be
preserved.
Caps do either work on a fs or they don't and they can be copied.

> * some filesystems don't support xattrs at all, and the package manager
>   needs to support installing to them, even if the user is building on
>   a filesystem that does support it
That's true, additionaly even if the fs is able to support xattr, there
are kernel options, which need to be set. I agree with you, that that's
a huge problem. We need to have a good fallback mechanism.

Zac metioned that we could have three modes for movefile:
1) no caps
2) tolerant mode, which does not fail if caps could not be copied
3) strict mode, which fails if caps can't be copied

ferringb metioned some kind of marker with which one can indicate xattr
support.

While GSoC I was not able to come up with a good fallback mechanism.
I'm going to give the new ideas some thought over the week and hopefully
come up with something good :).

> * tar and xattrs is a massive problem, so how do binaries work?
tar can be patched to support xattrs. If we want to use caps, we will
have to apply those patches too. (iirc Fedora already uses such
patches). 

> I think it'd help if you provided a description of how all the above
> (plus the other issues that I've forgotten about) can be handled.
I hope I cleared things up at least a bit :).

Cheers,
constanze

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Sun, Mar 06, 2011 at 05:34:29PM +0100, Constanze Hausner wrote:
> On 17:44 Sat 05 Mar     , Ciaran McCreesh wrote:
> > * tar and xattrs is a massive problem, so how do binaries work?
> tar can be patched to support xattrs. If we want to use caps, we will
> have to apply those patches too. (iirc Fedora already uses such
> patches). 

For binpkg, the approach I mentioned would remove the need to for tar 
to support xattrs- the same mechanism for the PM to tweak the perms 
would be usable.  So no need for tar/bsdtar to restore xattrs- it's 
undesirable anyways since as I mentioned, if the cap couldn't be 
applied for whatever reason it would result in a chmod -s binary being 
installed.

For src, I'd strongly be against restoration there.  It just opens up 
way too many surprises- a simple example is a tarball carrying the 
immutable flag.  Xattrs really should be specified by the ebuild (and 
applied by the PM) instead- far more controlled namely.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On Sun, 6 Mar 2011 17:34:29 +0100
Constanze Hausner <constanze@gentoo.org> wrote:

> On 17:44 Sat 05 Mar     , Ciaran McCreesh wrote:
> > * some filesystems don't support xattrs at all, and the package
> > manager needs to support installing to them, even if the user is
> > building on a filesystem that does support it
>
> While GSoC I was not able to come up with a good fallback mechanism.
> I'm going to give the new ideas some thought over the week and
> hopefully come up with something good :).

How about that:
1) src_install() installs a file, like in:
	/var/lib/gentoo/filecaps.d/${PF}
specifying which caps have to applied to which files,

2) the eclass depends on an ebuild, installing a kind
of 'filecaps-apply' tool, reading information from that file and trying
to apply filecaps as necessary (and flipping setuid bits),

3) the eclass calls that tool in pkg_postinst() to apply the caps
on the target filesystem.

This should help with all the issues mentioned, including binpkg
support. Moreover, user could use the tool manually to restore/reset
filecaps if they were lost or unapplied (e.g. due to incorrect kernel
config).

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4417 bytes --]

On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> On Sun, 6 Mar 2011 17:34:29 +0100
> Constanze Hausner <constanze@gentoo.org> wrote:
> 
> > On 17:44 Sat 05 Mar     , Ciaran McCreesh wrote:
> > > * some filesystems don't support xattrs at all, and the package
> > > manager needs to support installing to them, even if the user is
> > > building on a filesystem that does support it
> >
> > While GSoC I was not able to come up with a good fallback mechanism.
> > I'm going to give the new ideas some thought over the week and
> > hopefully come up with something good :).
> 
> How about that:
> 1) src_install() installs a file, like in:
> 	/var/lib/gentoo/filecaps.d/${PF}
> specifying which caps have to applied to which files,
> 
> 2) the eclass depends on an ebuild, installing a kind
> of 'filecaps-apply' tool, reading information from that file and trying
> to apply filecaps as necessary (and flipping setuid bits),
> 
> 3) the eclass calls that tool in pkg_postinst() to apply the caps
> on the target filesystem.

Exactly what benefit is derived from trying to step outside the PM for 
this, and trying to hack up what the PM already set for permissions?

General rule of thumb, the more the PM knows the better things are 
going to be for people, and for long term compatibility.  If 
in doubt consider the improvements to user experience via 
revdep-rebuild functionality making it into the PM; PM can actually 
plan for rebuilds as it goes rather than potentially blowing up a 
later build (or telling the user "go run xyz"). Consider:

1) this tool will have to grow system/user configuration for 
overrides- something the PM could fold in easily enough into it's 
existing capbilities.  If in doubt consider FEATURES=suidctl .

2) has to be prefix aware, including understanding of deprived.  This 
can be done mind you, but like #1, the bits are already there at the 
PM level.

3) the information recorded there is ultimately redundant when/if a 
sane VDB format gets created; as is this info could just as easily be 
pushed in there as a new file per CPV in the existant VDB format.

4) this requires further OOB handling for ID databases- handling that 
could've been pushed into the PM itself (admittedly a weak point since 
ID is already mildly screwed up here, but no point in making it 
worse).

5) it opens up a window in every merge where setuid binaries are on 
disk, just prior to your proposed tool getting ran.  This is annoying 
to say the least, and if the system has disabled setuid in full it's a 
window where the binaries aren't actually usable.

6) it's slower than just having the PM do it.  Specifically, the PM is 
already transfering the content to disk, and fiddling it's bits- 
adjusting the files modes and setting capability is something it can 
do on creation (eliminating #5) rather than having to shell out to 
some script.  It's important to realize that the area this slows down 
is a critical section for parallelized binpkg merging- something the 
chrome-os folk have ran into.

6) shifting it to an external tool means the format used by the tool 
needs standardization (rather than just being standardized via PMS) to 
allow interop when inevitably a PM author goes to fold the 
functionality into the PM.

7) this tool, due to it being not part of the PM, the PM has to go out 
of it's way to protect the depgraph for- something it should already 
be doing for itself.  External, it's another hardcoded constant (or 
addition to system set) the PM has to watch for- w/in the pm, it ought 
to pay attention to it as is.


> This should help with all the issues mentioned, including binpkg
> support. Moreover, user could use the tool manually to restore/reset
> filecaps if they were lost or unapplied (e.g. due to incorrect kernel
> config).

Every issue you've raised is addressable at the PM level- generally 
speaking, done better at the PM level.

Basically... please fix the problem at the correct location.  
Capabilities, xattrs, etc, are not a temporary fad- they're 
increasingly a core requirement of a linux system (thus the PM that 
manages it).  The place for this functionality is in the PM- more 
importantly, trying to do it outside of it just makes a bigger mess 
for PM/format authors when inevtiably it has to be pulled in.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Mon, 7 Mar 2011 03:40:23 -0800
Brian Harring <ferringb@gmail.com> wrote:

> On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> > This should help with all the issues mentioned, including binpkg
> > support. Moreover, user could use the tool manually to restore/reset
> > filecaps if they were lost or unapplied (e.g. due to incorrect
> > kernel config).
> 
> Every issue you've raised is addressable at the PM level- generally 
> speaking, done better at the PM level.
> 
> Basically... please fix the problem at the correct location.  
> Capabilities, xattrs, etc, are not a temporary fad- they're 
> increasingly a core requirement of a linux system (thus the PM that 
> manages it).  The place for this functionality is in the PM- more 
> importantly, trying to do it outside of it just makes a bigger mess 
> for PM/format authors when inevtiably it has to be pulled in.

Yes, you are completely right. PM should handle that, as well as it
can with current EAPIs, and even better with higher EAPI.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]

On Sat, Mar 05, 2011 at 02:24:22PM +0100, Constanze Hausner wrote:
> fcaps() {
> 	debug-print-function ${FUNCNAME} "$@"
> 	debug-print "${FUNCNAME}: Trying to set capabilities for ${4}"
> 	local uid_gid=$1
> 	local perms=$2
> 	export fallbackFileMode=$perms
> 	local capset=$3
> 	local path=$4

That export of fallbackFileMode looks pointless... clarify please.  
Also, your arg count checking here means it's going to throw some 
weird ass errors if people invoke it incorrectly.  You likely want a 

[ $# -ne 4 ] && die "wrong arg count"

thrown in there..


> 	if [ $# -eq 5 ]; then
> 		local set_mode=$5
> 	else
> 		debug-print "${FUNCNAME}: no set-mode provided, setting it to ep"
> 		#if there is no set_mode provided, it is set to true
> 		local set_mode=1
> 	fi
> 
> 	#set owner/group
> 	debug-print "${FUNCNAME}: setting owner and group to ${uid_gid}"
> 	chown $uid_gid $path
> 	if [ $? -ne 0 ]; then
> 		eerror "chown "$uid_gid" "$path" failed."
> 		return 2
> 	fi
> 
> 	#set file-mode including suid
> 	debug-print "${FUNCNAME}: setting file-mode ${perms}, including suid"
> 	chmod $perms $path

Arbitrary/user-controlled path's always need to be quoted...

> 	if [ $? -ne 0 ]; then
> 		eerror "chmod "$perms" "$path" failed."
> 		return 3
> 	fi
> 
> 	#if filecaps is not enabled all is done
> 	use !filecaps && return 0
> 
> 	#if libcap is not installed caps cannot be set
> 	if [ ! -f "/sbin/setcap" ]; then
> 		debug-print "${FUNCNAME}: libcap not installed, could not set caps"
> 		return 4
> 	fi
> 
> 	#Check for set mode
> 	if [ $set_mode -eq 1 ]; then
> 		debug-print "${FUNCNAME}: set-mode = ep"
> 		local sets="=ep"
> 	else
> 		debug-print "${FUNCNAME}: set-mode = ei"
> 		local sets="=ei"
> 	fi

Shift this into the initial arg processing; eliminates the need for 
set_mode and is simpler to follow.

> 
> 	#set the capability
> 	debug-print "${FUNCNAME}: setting capabilities"

lay off the debug-print's a bit...

> 	setcap "$capset""$sets" "$path" &> /dev/null
> 
> 	#check if the capabilitiy got set correctly
> 	debug-print "${FUNCNAME}: checking capabilities"
> 	setcap -v "$capset""$sets" "$path" &> /dev/null
> 
> 	local res=$?
> 
> 	#if caps could be set, remove suid-bit
> 	if [ $res -eq 0 ]; then
> 		debug-print "${FUNCNAME}: caps were set, removing suid-bit"
> 		chmod -s $path
> 	else
> 		debug-print "${FUNCNAME}: caps could not be set"
> 		ewarn "setcap "$capset" "$path" failed."
> 		ewarn "Check your kernel and filesystem."
> 		ewarn "Fallback file-mode was set."
> 	fi
> 
> 	return $res
> }

I'd take a different approach here; this code basically assumes that 
the PM knows of it- note the chmod -s.  The use flag protection you 
tried adding, without some profile hacks, is user modifiable- meaning 
users can flip it on even if the PM doesn't support it.

Or consider that the code above is purely doing it's thing during the 
install phase, specifically against whatever filesystem is used for 
building- while capabilities might be able to be set there, it's 
possible the final merge location won't support it.  End result of 
that is you'll get a setuid stripped binary merged to the 
livefs lacking the caps- borkage.  Or consider the inverse- the 
buildroot can't do capabilities, but the livefs could.  You get the 
idea.

Instead, write the code so the PM has to export a marker in some 
fashion to explicitly state "yes, I can do capabilities"- I'm 
specifically suggestining checking for a callback function exposed to 
the env.

If that function isn't there, then the PM can't do it- end of story.  
If it is, the PM takes the args and will try to apply the 
capabilities at the correct time- stripping setuid/setgid if it 
succeeds.

Please go that route; and please do not stick "portage" into the 
function name, something generic we can use for a later EAPI is 
better.

Implementing it as I suggested has the nice side affect of not being 
limited by PMS also, although it's an approach that still requires 
planning for compatibility.

Thanks-
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Constanze Hausner]

On 03:01 Sun 06 Mar     , Brian Harring wrote:
[snip]
Thanks for your feedback, your remarks were correct :). I updated the
eclass appropriately.

> I'd take a different approach here; this code basically assumes that 
> the PM knows of it- note the chmod -s.  The use flag protection you 
> tried adding, without some profile hacks, is user modifiable- meaning 
> users can flip it on even if the PM doesn't support it.
> 
> Or consider that the code above is purely doing it's thing during the 
> install phase, specifically against whatever filesystem is used for 
> building- while capabilities might be able to be set there, it's 
> possible the final merge location won't support it.  End result of 
> that is you'll get a setuid stripped binary merged to the 
> livefs lacking the caps- borkage.  Or consider the inverse- the 
> buildroot can't do capabilities, but the livefs could.  You get the 
> idea.
> 
> Instead, write the code so the PM has to export a marker in some 
> fashion to explicitly state "yes, I can do capabilities"- I'm 
> specifically suggestining checking for a callback function exposed to 
> the env.
> 
> If that function isn't there, then the PM can't do it- end of story.  
> If it is, the PM takes the args and will try to apply the 
> capabilities at the correct time- stripping setuid/setgid if it 
> succeeds.
> 
> Please go that route; and please do not stick "portage" into the 
> function name, something generic we can use for a later EAPI is 
> better.
> 
> Implementing it as I suggested has the nice side affect of not being 
> limited by PMS also, although it's an approach that still requires 
> planning for compatibility.
I'm currently in search of a good fallback mechanism respectivly a good
mechanism to deal with cap-setting in src_install. As I already said in
my mail to ciaran, I'm going to give the new ideas some thought :).

Cheers,
constanze

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Constanze Hausner]

> > I'd take a different approach here; this code basically assumes that 
> > the PM knows of it- note the chmod -s.  The use flag protection you 
> > tried adding, without some profile hacks, is user modifiable- meaning 
> > users can flip it on even if the PM doesn't support it.
> > 
> > Or consider that the code above is purely doing it's thing during the 
> > install phase, specifically against whatever filesystem is used for 
> > building- while capabilities might be able to be set there, it's 
> > possible the final merge location won't support it.  End result of 
> > that is you'll get a setuid stripped binary merged to the 
> > livefs lacking the caps- borkage.  Or consider the inverse- the 
> > buildroot can't do capabilities, but the livefs could.  You get the 
> > idea.
> > 
> > Instead, write the code so the PM has to export a marker in some 
> > fashion to explicitly state "yes, I can do capabilities"- I'm 
> > specifically suggestining checking for a callback function exposed to 
> > the env.
> > 
> > If that function isn't there, then the PM can't do it- end of story.  
> > If it is, the PM takes the args and will try to apply the 
> > capabilities at the correct time- stripping setuid/setgid if it 
> > succeeds.
> > 
> > Please go that route; and please do not stick "portage" into the 
> > function name, something generic we can use for a later EAPI is 
> > better.
> > 
> > Implementing it as I suggested has the nice side affect of not being 
> > limited by PMS also, although it's an approach that still requires 
> > planning for compatibility.
> I'm currently in search of a good fallback mechanism respectivly a good
> mechanism to deal with cap-setting in src_install. As I already said in
> my mail to ciaran, I'm going to give the new ideas some thought :).

After some discussions with ferringb we came to the conclusion, that his
proposal to implement the cap-setting function in the PMS would be for
the best ;).

So for supporting filebased-caps, we need all PMS to provide a function
which: 
- gets the final path and the caps to set, tries to set them and then
removes the suid-bit
- returns 0 or 1, indicating success or failure

If the user's setting doesn't allow caps, then the function is not
available.

Additionally we could also pass the fallback-filemode to the PMS, so it
could do the suid-setting itself, but this would be optional.

So PMS-Guys, please tell me what you think about that and if I can help
in any way. Filebased-caps could really help to have more secure systems
:).

btw, the eclass will be adapted, of course ;).

Cheers,
Constanze