On 2018-10-27, Ed Maste <ema...@freebsd.org> wrote: > On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai <cyp...@cyphar.com> wrote: > > > > +#ifndef O_BENEATH > > +#define O_BENEATH 00040000000 /* *Not* the same as capsicum's > > O_BENEATH! */ > > +#endif > [...] > 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.
What is the proposed semantic of O_BENEATH with absolute paths -- I believe you don't have an openat(2) on FreeBSD (but please feel free to correct me)? > 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. I'm going to send out a v4 "soon" but I would like to know what folks think about having resolveat(2) (or similar) to separate the scoping O_* flags and produce an O_PATH -- since unsupported O_* flags are ignored by older kernels userspace will have to do some plenty of checking after each path operation. Personally, I believe this (along with AT_EMPTY_PATH for openat(2)) would help with some other O_PATH issues. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
signature.asc
Description: PGP signature
