From: "Theo de Raadt" Subject: Re: fix calendar -a To: Alexander Bluhm , tech Date: Mon, 16 Mar 2026 11:56:09 -0600 Crystal Kolipe wrote: > 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()? No program in the tree uses unveil without locking it. If you want to draw outside the lines, I'll break your code.