From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-93350-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 104627 invoked by alias); 18 Jun 2018 17:13:01 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 104449 invoked by uid 89); 18 Jun 2018 17:13:01 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*r:4.89
X-HELO: albireo.enyo.de
From: Florian Weimer <fw@deneb.enyo.de>
To: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] Linux: Implement opensock using Netlink sockets
References: <20180618105015.5E8B340292859@oldenburg.str.redhat.com>
	<1529340418.2289.267.camel@codethink.co.uk>
Date: Mon, 18 Jun 2018 17:13:00 -0000
In-Reply-To: <1529340418.2289.267.camel@codethink.co.uk> (Ben Hutchings's
	message of "Mon, 18 Jun 2018 17:46:58 +0100")
Message-ID: <87602guijp.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2018-06/txt/msg00504.txt.bz2

* Ben Hutchings:

> On Mon, 2018-06-18 at 12:50 +0200, Florian Weimer wrote:
>> inet/tst-inet6_scopeid_pton uses __opensock indirectly, to call ioctl
>> with SIOCGIFINDEX, and it still works after this change.
>>=20
>> 2018-06-18=A0=A0Florian Weimer=A0=A0<fweimer@redhat.com>
>>=20
>> 	* sysdeps/unix/sysv/linux/opensock.c (__opensock): Unconditionally
>> 	return a Netlink socket.
>> 	* sysdeps/unix/sysv/linux/s390/opensock.c: Remove file.
> [...]
>
> I agree that we can assume the kernel implements AF_NETLINK, but the
> available socket address families might be restricted by a security
> policy (e.g. systemd's RestrictAddressFamilies property).  I'm not sure
> whether it's safe to assume that they will always allow AF_NETLINK.

If it actually worked, the AF_NETLINK approach seems cleaner in this
regard.  The current code goes hunting for information in /proc (to
avoid loading unwanted kernel modules), which requires a much larger
footprint and is harder to filter.