|UNVEIL(2)||System Calls Manual||UNVEIL(2)|
unveil — unveil
parts of a restricted filesystem view
char *path, const char
The first call to
removes visibility of the entire filesystem from all other
filesystem-related system calls (such as
rename(2)), except for the
specified path and
system call remains capable of traversing to any path
in the filesystem, so additional calls can set permissions at other points
in the filesystem hierarchy.
After establishing a collection of path and
permissions rules, future calls to
can be disabled by passing two
Alternatively, pledge(2) may
be used to remove the "unveil" promise.
The permissions argument points to a string consisting of the following characters:
A path that is a directory will enable all
filesystem access underneath path using
permissions if and only if no more specific matching
exists at a lower level. 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
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
and still appear to exist.
Attempts to access paths not allowed by
will result in an error of
EACCES when the
permissions argument does not match the attempted
ENOENT is returned for paths for which no
unveil() permissions qualify. After a process has
will mark it with the ‘U’ flag if file access was prevented by
use can be tricky because programs misbehave badly when their files
unexpectedly disappear. In many cases it is easier to unveil the directories
in which an application makes use of files.
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error.
unveil() system call first appeared in
|July 25, 2019||OpenBSD-6.6|