Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 06 Sep 2012 13:47:27 +0200
From: Igmar Palsenberg <>
Subject: Re: capset() capget() syscalls

>> It is an unclear situation. Glibc seems inconsistent.
>> Personally I think Musl should provide the kernel structures and
>> syscalls for everything that is not deprecated.
> In principle, I agree with you.
> My impression was that the kernel developers intend for this API to be
> deprecated for use by applications, and the only reason they haven't
> replaced it with a proper kernelspace API is that they assume you'll
> be using libcap which wraps/hides the ugliness (and replaces it with
> something else that's just ugly in different ways...).
> As such, it's sort of a borderline case. Do we really want to be
> promoting this API for use by applications?

I haven't seen a discussion on the capset() capget() API in ages in
lkml. My guess : It won't change any time soon.
It's use is very specific, so that narrows the change that it will change.

About the issue if we want to promote this : Yes, when it comes to
capabilities. Most apps don't need full access,
but only a subset of it (who wants to unload kernel modules from an
application ?). I'm a capabilities fan, not a fan of the API.

>> I agree with Linus, provide all the headers in libc. I tried to write
>> some code to include all syscalls and constants needed for them, and
>> as far as I can see it is impossible with glibc due to conflicts. If
>> anyone has a set of includes that works let me know....
> Can you explain what you mean here?
Linus' opinion is that including kernel headers in userspace code is the
road to destruction of this world. Or something
close ;)


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.