semarie@ reported this last year.
https://marc.info/?t=154055857000005&r=1&w=2
On Sat, Jun 08, 2019 at 03:12:19PM +0200, Klemens Nanni wrote:
> kern.version=OpenBSD 6.5-current (GENERIC.MP) #6: Tue Jun 4 15:05:10 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>
> Unveiling nonexistent files on read-only filesystems always results in
> EROFS regardless of permissions:
>
> $ mount | grep '/usr '
> /dev/sd1d on /usr type ffs (local, nodev, read-only)
> $ ls /usr/nonexistent
> ls: /usr/nonexistent: No such file or directory
> $ cat test.c
> #include <err.h>
> #include <unistd.h>
> int main(void) {
> if (unveil("/usr/nonexistent", "") == -1)
> err(1, "unveil");
> return 0;
> }
> $ cc test.c && ./a.out
> a.out: unveil: Read-only file system
>
> According to unveil(2)
>
> 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.
>
> Yet, this breaks when when the underlaying filesytem is not writable.
> Just like the existence of the file, filesystem write access may change
> during runtime.
>
> Different permissions have no effect on this: "", "r", "rw", "rwc" all
> yield EROFS.
>
> I noticed this during `pkg_add -u` which runs update-desktop-database(1).
> It unveils directories with "r" permissions before looking for .desktop
> files in them, see
> /usr/ports/devel/desktop-file-utils/patches/patch-src_update-desktop-database_c.
> Here is
>
> $ ls /usr/share/applications
> ls: /usr/share/applications: No such file or directory
> $ update-desktop-database
> Can't unveil '/usr/share/applications' directory: Read-only file system
> The databases in [/usr/local/share/applications,
> /usr/share/applications] could not be updated.
>
>
