On 2026/03/16 17:43, Crystal Kolipe 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()?
> 

unveil is not locked, there is neither a pledge (without 'unveil' in
promises) nor a unveil (NULL, NULL)