On Wed, Apr 30, 2025 at 3:33 AM Stuart Henderson <stu@spacehopper.org> wrote:
> subsequent calls open up ("unveil") access to other files/dirs, this is
> repeated until all wanted dirs are "unveiled", the list is then locked.
> the mechanism doesn't allow "permit /foo but deny /foo/bar".

It seems like you overlooked the function of unveil entirely as
described in the unveil.2 man page:

> will enable all filesystem access underneath path using permissions
>  **if and only if no more specific matching unveil() exists** at a lower level.

In other words: if an unveil exists for the whole file path or
anything more specific,
then the other unveil() for the path above is expected to Not enable
any permissions
for anything matching that more-specific file path unveil.


> Directories are remembered at the time of a call to unveil(). This means that a
> directory that is removed and recreated after a call to unveil() will appear to not exist.

> Non-directory paths are remembered by name within their containing directory,
> and so may be created, removed, or re-created after a call to unveil() and still
> appear to exist.

> Attempts to access paths not allowed by unveil() will result in an error of EACCES

-- 
-JA