[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120906141132.GC27715@brightrain.aerifal.cx>
Date: Thu, 6 Sep 2012 10:11:32 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: capset() capget() syscalls
On Thu, Sep 06, 2012 at 01:36:24PM +0200, Igmar Palsenberg wrote:
> 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.
The problem with these is that the typedefs are defined to the
pointer-to-struct type, not the struct type, and the actual struct
type seems to have a name that's not meant to be used by applications
(_-prefixed). This makes it impossible to actually declare objects of
the necessary type. And using typedef to a pointer type instead of the
base object type when you're not dealing with an 100% opaque type is
just Considered Harmful...
> We might consider altering the naming a bit. The __u32 stuff can be
> replace by proper typing.
Yes, that's not what I was talking about; it's easy to fix.
Rich
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.
