Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 27 Oct 2018 01:41:14 +0000
From:   Ed Maste <emaste@freebsd.org>
To:     cyphar@cyphar.com, David Drysdale <drysdale@google.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] namei: implement O_BENEATH-style AT_* flags
Message-ID: <20181027014114.GA52393@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181009065300.11053-3-cyphar@cyphar.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> +#ifndef O_BENEATH
> +#define O_BENEATH      00040000000 /* *Not* the same as capsicum's O_BENEATH! */
> +#endif

I had originally followed up privately to Aleksa about this comment (to
suggest that it's outdated and should be removed), but the reference
Capsicum implementation now supports O_BENEATH and I think it's sensible to
follow up here with the additional context.

O_BENEATH originally came from the Capsicum Linux port, and inherited the
restriction against ".." path components from years ago when the port was
done.  In addition, FreeBSD did not originally implement O_BENEATH as the
"beneath" behaviour is inherently provided once a process enters a
capability mode sandbox.  However, Capsicum now allows ".." paths, and
FreeBSD supports O_BENEATH separately from capability mode.  Absolute paths
are not yet allowed with O_BENEATH but a change is in review to permit them.
 
On FreeBSD a lookup prevented by O_BENEATH semantics returns ENOTCAPABLE,
the errno coming from the Capsicum implementation.

Ideally I would like to see us have the same API; none of this work has yet
shipped in a FreeBSD release and there is an opportunity for us to make
changes to match the interface and errors Linux may adopt.