Re: capset() capget() syscalls

[Rich Felker <dalias@aerifal.cx>]

On Wed, Sep 05, 2012 at 11:28:54AM +0200, Igmar Palsenberg wrote:
> 
> >> Hi,
> >>
> >> Attached patch adds types to the existing syscalls, and defines the
> >> types in the header. All CAP_* defines are also added.
> > I'm curious what applications expect this header and definitions.
> > glibc does not have such a header. My impression is that it might have
> > existed at some point but that it was removed a long time ago, and
> > that any use of capabilities without libcap (which presumably contains
> > its own copy of the definitions for interfacing with the kernel) was
> > long ago deprecated.
> >
> > Can you clear these issues up?
> My own. Those definitions are part of the kernel syscall. While glibc
> does support structure definitions for most syscalls,
> capabilities seem to be an exception. (they are in linux/capabilities.h
> to be exact). Oh, and I really dislike the interfaces libcap provides.

I found them pretty ugly too, but I can't say I like the kernel API
any better... And the API in linux/capabilities.h is just horrible.
The typedefs are pointer types and there's no way to actually declare
the objects they point to without using the _-prefixed struct tag. I
don't see why they needed this hideous struct-pointer-based interface
rather than just passing a few words as syscall arguments...

> I pull those definitions in myself now, because pulling in kernel header
> files is considered a bad practice (c) Linus Torvalds
> Since these won't add a byte of code, it might be a good idea.
> I'm open for suggestions however.

There are a lot of direct-kernel-interface-usage situations that
require pulling in the associated kernel headers, such as fb.h, kb.h,
etc. One issue is that the kernel headers presumably lack prototypes
for the functions, but the most portable way to do what you're doing
is probably going to be:

#include <linux/capabilities.h>
#include <sys/syscall.h>
...
syscall(SYS_capset, x, y);

At least this will work on every Linux libc I know of, and it's
hard for them to break it.

If you really want to see the header in musl, I'm not opposed to
further consideration of the matter, but right now I don't think
adding it promotes portable software; rather it seems to promote
writing software that works on musl and breaks on glibc.

Rich