From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751677AbdEHXKA (ORCPT ); Mon, 8 May 2017 19:10:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40672 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbdEHXJ6 (ORCPT ); Mon, 8 May 2017 19:09:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E4B8D80C02 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dhowells@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E4B8D80C02 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <149382747487.30481.15428192741961545429.stgit@warthog.procyon.org.uk> <149382750838.30481.8003919639826341255.stgit@warthog.procyon.org.uk> To: Miklos Szeredi Cc: dhowells@redhat.com, viro , linux-fsdevel , linux-nfs@vger.kernel.org, lkml Subject: Re: [PATCH 4/9] Implement fsopen() to prepare for a mount MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11117.1494284995.1@warthog.procyon.org.uk> Date: Tue, 09 May 2017 00:09:55 +0100 Message-ID: <11118.1494284995@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 08 May 2017 23:09:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi wrote: > Someone also suggested using /dev/fs/${FSTYPE} to open the fsfd. The downside of using open() for this is that you then have a chicken-and-egg problem with respect to booting as you point out. > I realize that does not have the namespace info that you also want to add, > but wondering if that really has to come from open and cannot be set later? When do you do the security checks? Those are going to be affected by the namespaces. Other things are as well, such as setting hostnames, IP addresses, device file paths and default UIDs/GIDs, but these are probably more okay with being deferred to the parameter validation step. > ALTERNATIVES are /proc/fs/${FSTYPE}/dev or /sys/fs/${FSTYPE}/dev. > > Obviously neither can be used for bootstraping but there's still old > mount(2) for that. It should also be possible to build-time disable mount(2) in future. Obviously, this would mean providing other vectors for the other functions of mount(2). David