linux-kernel - Re: For review: pid_namespaces(7) man page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1362425267.7276.1@driftwood>
Date:	Mon, 04 Mar 2013 13:27:47 -0600
From:	Rob Landley <rob@...dley.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	mtk.manpages@...il.com, linux-man <linux-man@...r.kernel.org>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: For review: pid_namespaces(7) man page

On 03/03/2013 10:03:55 PM, Eric W. Biederman wrote:
> Rob Landley <rob@...dley.net> writes:
> 
> > On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
> >> > And yet the glibc guys insist on #define
> >> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
> >> > order to access this Linux-specific feature which has nothing
> >> whatsoever to
> >> > do with the FSF.
> >>
> >> This is a misunderstanding. _GNU_SOURCE is the standard way to  
> expose
> >> Linux-specific functionality from POSIX header files.
> >
> > What standard? The Linux kernel is not, and never was, part of the  
> GNU
> > project.
> 
> Is the argument that there should be a _LINUX_SOURCE directive in  
> glibc
> for this?

If you don't #define any feature test macros at all, you get a bunch of  
macros (_BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE,  
_POSIX_C_SOURCE=200809L, and so on) defined by default in features.h.  
If you start defining macros, several of the default ones _go_away_,  
and you start missing things that are defined by posix-2008. Yes,  
defining feature test macros makes definitions _vanish_ out of the  
headers, which means feature test macros can actually reduce code  
portability.

The _GNU_SOURCE is glibc's way of saying "switch on everything glibc  
offers". (Except it isn't _quite_, but that seems to be what they  
intended.) So there are various things that test _specifically_ for  
that macro, but the macro also switches on (from features.h):

/* If _GNU_SOURCE was defined by the user, turn on all the other  
features.  */
#ifdef _GNU_SOURCE
# undef  _ISOC95_SOURCE
# define _ISOC95_SOURCE 1
# undef  _ISOC99_SOURCE
# define _ISOC99_SOURCE 1
# undef  _POSIX_SOURCE
# define _POSIX_SOURCE  1
# undef  _POSIX_C_SOURCE
# define _POSIX_C_SOURCE        200809L
# undef  _XOPEN_SOURCE
# define _XOPEN_SOURCE  700
# undef  _XOPEN_SOURCE_EXTENDED
# define _XOPEN_SOURCE_EXTENDED 1
# undef  _LARGEFILE64_SOURCE
# define _LARGEFILE64_SOURCE    1
# undef  _BSD_SOURCE
# define _BSD_SOURCE    1
# undef  _SVID_SOURCE
# define _SVID_SOURCE   1
# undef  _ATFILE_SOURCE
# define _ATFILE_SOURCE 1
#endif

This is not fine-grained control of what libc exports. This is "if you  
want to use unshare() then everything we ever implemented gets  
simultaneously exported into your namespace". (Which it _mostly_ is if  
you never use any feature test macros, but not the Linux-specific  
system calls.)

The new musl-libc.org did an _ALL_SOURCE macro that just enables every  
feature test macro they implemented. (That's its definition, it's the  
feature test macro that says feature test macros area bad idea.)

> Although come to think of it I can't imagine how <sched.h> is a POSIX
> header.  Last I looked it only had linux specific bits in it.  Which
> makes needing any kind of #define strange.

My objection is that Linux system calls are not part of the GNU  
project. Requiring that macro to get Linux system calls out of bionic,  
uClibc, klibc, musl, olibc, dietlibc, or newlib is _silly_. It's the  
"GNU/Linux" prefix imposed on the source level, and it's a fairly  
recent development (I've only noticed it since 2008 or so).

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/