On Mon, Mar 16, 2026 at 11:25:46AM -0600, Theo de Raadt wrote:
> Crystal Kolipe <kolipe.c@exoticsilicon.com> wrote:
> 
> > On Mon, Mar 16, 2026 at 11:01:43AM -0600, Theo de Raadt wrote:
> > > Stuart Henderson <stu@spacehopper.org> wrote:
> > > 
> > > > On 2026/03/16 10:45, Theo de Raadt wrote:
> > > > > I doubt you need "rx".
> > > > > 
> > > > > Does "x" not work?
> > > > 
> > > > it does, but / is already unveiled 'r' so using just 'x' for those
> > > > doesn't seem any better?
> > > 
> > > Whoa, I am hearing a big misunderstanding.
> > > 
> > > Unveil creates a series of nested enclaves.
> > > 
> > > The permissions from a higher level are IRRELEVANT in a nested enclave.
> > 
> > This misunderstanding about unveil() keeps coming up in one form or another:
> > 
> > https://marc.info/?l=openbsd-tech&m=174600467800474
> 
> That is more than a misunderstanding.  That code is ignoring the manual
> page.
> 
> The Unveil system is never activated in that code.

The behaviour of the program seems to match what the manual page says:

" ENOENT is returned for paths for which no unveil() permissions qualify "

With unveil("foo/bar", "") the last call to open() fails with ENOENT.

Removing unveil("foo/bar", ""), the last call to open() succeeds.

So the required behaviour of "permit foo, but deny foo/bar" is achieved.

Why is this not a valid use of unveil()?