[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50488AB8.5090002@palsenberg.com>
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.
