Date: Thu, 06 Sep 2012 13:36:24 +0200 From: Igmar Palsenberg <igmar@...senberg.com> To: musl@...ts.openwall.com Subject: Re: capset() capget() syscalls On 9/5/12 4:24 PM, Rich Felker wrote: > 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... You only need cap_user_header_t and cap_user_data_t, and the CAP_ defines. The rest belongs to libcap, and aren't used by the kernel API. We might consider altering the naming a bit. The __u32 stuff can be replace by proper typing. >> 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); I prefer leaving out kernel headers in my code. This old project uses an old netfilter API, and still builds (I pulled the defined in). It breaks at runtime, but that's a differerent story :) > 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. The code is in libcap only. Glibc just provides the syscall interfaces AFAIK. Igmar
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.