Hi!
On Sat, 2008-10-18 at 06:03:59 +0200, Håvard Moen wrote:
> Package: dpkg
> Version: 1.14.22
> Severity: wishlist
>
> With the support for file capabilities in the kernel (which can be set
> using the programs from libcap2-bin), it would be nice if
> dpkg-statoverride supported this so that the use of setuid programs can
> be reduced.
Yes, although there's several problems to consider before doing this,
and there's the question of just implementing dpkg-statoverride
support or general fcaps for packages. I think just starting with the
former would be the best for now, and then we can consider the latter.
Statoverride fcaps:
* Only needs support in dpkg-statoverride and dpkg at unpack time.
* As the admin is the one in charge, dealing with unsupported
systems/file-systems/etc would be easier.
General fcaps:
* A way to ship the fcaps in the packages:
- either add a new control file for additional metadata,
- or add pax style tar archive support.
* Take into account systems no supporting fcaps, this includes:
- (for now) non-Linux systems,
- Linux w/ old kernels or kernels w/o fcap compiled in,
- file systems not supporting fcaps, and/or w/o mount time enabled
xattr.
Ideally all those would need to fallback to using suid root again,
and so we'd need to mark them with both set of flags.
* We'd need to store that metadata somewhere so it can be restored
in case it "gets lost". Most apps do not carry over xattr by default.
Those are the thoughts I remember from my initial check few months
ago, there's been discussion in the Fedora mailing list which is worth
taking a look at:
<http://thread.gmane.org/gmane.linux.redhat.fedora.devel/96291>
And also to the site which has been keeping track of the fcaps status
in Linux all this years:
<http://www.friedhoff.org/posixfilecaps.html>
regards,
guillem
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
