[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50488D4F.8000703@palsenberg.com>
Date: Thu, 06 Sep 2012 13:47:27 +0200
From: Igmar Palsenberg <igmar@...senberg.com>
To: musl@...ts.openwall.com
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 ;)
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.
