Stuart Henderson <[email protected]> wrote: > > On Feb 18, it was changed like this: > > > > @@ -211,7 +211,11 @@ main(int argc, char **argv) > > argc -= optind; > > argv += optind; > > > > - if (pledge("stdio rpath tmppath", NULL) == -1) > > + if (unveil("/tmp", "rwc") == -1) > > + err(2, "unveil /tmp"); > > + if (unveil("/", "r") == -1) > > + err(2, "unveil /"); > > + if (pledge("stdio rpath wpath cpath", NULL) == -1) > > err(2, "pledge"); > > > > /* > > > > > > I cannot think of any reason why that would fail. That's classic unveil > > + pledge use. > > > > It's because of a stacked mount (/usr/obj MFS on top of /usr/obj disk) >
That is very much related to what vfs_lookup.c 1.91 was trying to fix. But now we have a mountpoint on a mountpoint, and the change cannot understand that. revision 1.91 date: 2026/03/03 17:43:40; author: beck; state: Exp; lines: +2 -1; commitid: igJJ5tcpzCDiqt1r; Unveil fix for traversing up at a mount point in vfs_lookup. This fixes an issue where we could use the wrong unveil when we had a path starting with a .. starting from a directory that was a mount point, and also was unveiled. The fix ensures we remember traversing the unveil before descending into the underlying filesystem. fix by semarie@ with testing by me and deraadt@ and others ok deraadt@
