From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1842 Path: news.gmane.org!not-for-mail From: Igmar Palsenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: capset() capget() syscalls Date: Thu, 06 Sep 2012 13:47:27 +0200 Message-ID: <50488D4F.8000703@palsenberg.com> References: <20120905061905.GQ27715@brightrain.aerifal.cx> <50471B56.8040804@palsenberg.com> <20120905142441.GT27715@brightrain.aerifal.cx> <20120906030406.GY27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1346932061 18383 80.91.229.3 (6 Sep 2012 11:47:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2012 11:47:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1843-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 06 13:47:43 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T9aYg-0006Zn-IW for gllmg-musl@plane.gmane.org; Thu, 06 Sep 2012 13:47:42 +0200 Original-Received: (qmail 17551 invoked by uid 550); 6 Sep 2012 11:47:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17543 invoked from network); 6 Sep 2012 11:47:39 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 In-Reply-To: <20120906030406.GY27715@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1842 Archived-At: >> 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