From: Crystal Kolipe Subject: Re: fix calendar -a To: Alexander Bluhm , tech Date: Mon, 16 Mar 2026 17:43:45 +0000 On Mon, Mar 16, 2026 at 11:25:46AM -0600, Theo de Raadt wrote: > Crystal Kolipe wrote: > > > On Mon, Mar 16, 2026 at 11:01:43AM -0600, Theo de Raadt wrote: > > > Stuart Henderson 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()?