On Mon, Mar 16, 2026 at 11:56:09AM -0600, Theo de Raadt wrote:
> Crystal Kolipe <kolipe.c@exoticsilicon.com> wrote:
> 
> > 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()?
> 
> No program in the tree uses unveil without locking it.

OK, fair point Theo, thanks for the quick reply.

But this was just a POC to show the behaviour of more restrictive unveil()
permissions on a subdirectory.

I'd never leave it unlocked in real production code.

> If you want to draw outside the lines, I'll break your code.

Feedback is always appreciated.  Thanks again.