> On Jan 12, 2017, at 2:26 PM, Jakub Bogusz <[email protected]> wrote:
>
> By the way - are there any plans to implement fcaps in rpm5?
> (like in rpm.org since 4.7.0)
>
> e.g. mtr.spec looks sad with
> %attr(4755,root,root) %{_bindir}/mtr
> instead of %caps(cap_net_raw=ep)…
>
The problem I have with capabilities in RPM attached to files is how to
represent the values.
Adding an entire array for every file in order to attach a couple of values is
rather overkill.
Even if the tag is optional (which has other runtime issues testing return
codes everywhere),
its kinda hard (IMHO) to justify the bloat for the handful of files that would
benefit from capabilities.
There’s some subtle hackery that could be done for efficiency, but the hackery
would
most definitely be incompatible with the existing rpm.org representation.
And if capabilities are implemented, then act’s and xattr’s (beyond SELinux)
likely should be implemented too.
(aside)
What RPM needs is a way to handle sparse arrays, with memorization for repeated
values. This
is one of (of many) constraints on the existing header format. I am currently
looking at
flatcc flat buffers as a possible replacement for existing Headers, and there
is some
hope that flat buffers can/will handle
* a sparse array (for capabilities and other sparse arrays),
* a mapping (to replace RPM_I18NSTRING_TYPE removal)
* an array of RPM_BIN_TYPE (so that file digests don’t need to be
represented in hex)
but I’m some months away from attempting flat buffers in “production” RPM.
The rpm.org syntax could be parsed pretty easily, with associated
ignore/warning/error messages
if that helps. However implementing the syntax without adding the values to a
header
likely creates False Hope for users, and I’m trying to resist adding
bloat/change everywhere
to support capabilities as a “feature”.
Does my explanation make sense?
I’m certainly willing to discuss further if you wish, can easily generate a
patch for you
(but I’d like not to maintain that patch upstream, “legacy compatibility”
usually
takes years to undo or fix correctly in RPM.
AFAIK there’s only a handful of files that benefit from capabilities (but I
haven’t looked recently: for all I know
there may be tens of thousands of files that now use/need capabilities these
days).
FWIW: handling capabilities (and acls/xattrs) within %post/%preun/%verifyscript
scriptlets isn’t
all *THAT* ugly. JMHO, YMMV.
_______________________________________________
pld-devel-en mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
