On Tue, 16.12.14 17:22, Filipe Brandenburger (filbran...@google.com) wrote:

> On Wed, Dec 10, 2014 at 4:11 AM, Lennart Poettering
> <lenn...@poettering.net> wrote:
> > In fact, I think we should drop the
> > libcap dependency altogether and just do the two syscalls it offers to
> > us natively in systemd code. Neither is libcap a particularly nice
> > library, nor is the stuff it does particularly complex, hence we can
> > as well wrap the two calls we need in our code.
> I started looking at this and I just sent a patch set to remove the
> include of <sys/capability.h> where it was not really in use.
> Regarding the valid uses of libcap, it looks like the non-trivial part
> is cap_to_text/cap_from_text which we would have to reimplement and
> possibly keep them in sync with libcap.

Yeah, this is indeed not the nicest code to hack up, but should be
quite doable still.

> libcap also tries to support kernels which only support 32-bit
> capabilities. If we replace that code, should we make an assumption of
> 64-bit capabilities and just use a uint64_t to represent the bits?

I think 64bit caps have been standard since a loooong time
already. AFAIK though the kernel/userspace API is built around arrays
of 64bit values currently though, to allow extension one day. This is
how we expose it in sd-bus for the message metadata caps currently,
maybe we should do it everywhere the same.

> Let me know if you think this is something worth doing and I can
> contribute an implementation.

Absolutely. Would love to drop the dep!


Lennart Poettering, Red Hat
systemd-devel mailing list

Reply via email to