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.
