Fedora 11: moving to posix file capabilities?

[Panu Matilainen]

On Thu, 30 Oct 2008, seth vidal wrote:

> On Thu, 2008-10-30 at 20:41 +0200, Panu Matilainen wrote:
>> On Thu, 30 Oct 2008, seth vidal wrote:
>>
>>> On Thu, 2008-10-30 at 20:25 +0200, Panu Matilainen wrote:
>>>> On Wed, 29 Oct 2008, Steve Grubb wrote:
>>>>
>>>>> On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
>>>>>> We have kernel support for storing capabilities on filesystem since 2.6.24
>>>>>> and recent libcap, both in F9 already.
>>>>>
>>>>> And we have also been busy updating everything else to support this:
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=449984
>>>>
>>>> Ah, thanks for the pointer.
>>>>
>>>>>
>>>>>> I just committed file capability support to rpm.org HEAD, filling in the
>>>>>> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
>>>>>> but no reason they can't be pulled into 4.6.1 which is easily in F11
>>>>>> timeframe.
>>>>>
>>>>> We tried to support this in F-10 by having a test run with ping. We figured
>>>>> that is a simple well defined app that could be used as a test subject. We
>>>>> opened bz 455713 to document the change over. Turns out that people compile
>>>>> their own kernels and do not necessarily turn this on. So, what do we do in
>>>>> that case?
>>>>
>>>> People compiling their own kernels can hose their systems more
>>>> dramatically than this...
>>>>
>>>>>
>>>>>> Are we ready to start considering moving away from SUID bits to
>>>>>> capabilities, in Fedora 11 maybe?
>>>>>
>>>>> We tried and got turned back. How does rpm work on kernels that do not support
>>>>> file capabilities? I'd like to see us get past the initial objections so that
>>>>> we can start removing some of the setuid bits.
>>>>
>>>> Right now, installation of a package using capabilities will fail entirely
>>>> if kernel/filesystem doesn't support setting capabilities. Packages with
>>>> capabilities in them require rpmlib(FileCaps) feature, which rpm currently
>>>> provides if built with libcap support. It could (and probably should,
>>>> anyway) be made into a run-time tested feature, so that you'll get
>>>> something like this if running on kernel with no capability support:
>>>>
>>>> error: Failed dependencies:
>>>>  	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...
>>>
>>> Except nothing really watches those rpmlib() deps much at all, does it?
>>
>> Rpm itself does, so unless you use --nodeps (or the API equivalent of
>> that) it'll get caught before transaction starts.
>
> but after you've downloaded everything.

Yes, if you filter them out of the repository metadata. Rather than filter 
all of them out, filter just the "well duh" things like 
rpmlib(CompressedFileNames) out? The rpmlib(foo) dependencies are an 
important mechanism for tracking support for new features, it's just that 
as there haven't been any in several years they've started looking 
completely moot.

> And what provides those things these days?

In rpm 4.6.0, you can get the rpmlib provides as a dependency set with 
rpm.ds.Rpmlib() in python. I don't remember off-hand how it worked for 
older versions.

 	- Panu -