5 ms·

I don't understand how unveil works for applications which ask the user to supply a file to work on, as the app can't pre-declare where in the file system the u

I don't understand how unveil works for applications which ask the user to supply a file to work on, as the app can't pre-declare where in the file system the user might want to go to. For example, how would a word processor allow a user to select an arbitrarily located document to edit? Or is there some exception mechanism which allows any directory path that the user selected manually?

q3k 7y ago
IIUC, you would usually have a separate subprocess responsible for file access only, communicating over IPC with a less trusted and more complex process (eg. one that parses documents and renders fonts). See: architecture of acme-client(1): https://kristaps.bsd.lv/acme-client/ https://kristaps.bsd.lv/acme-client/
the8472 7y ago
Pledge and unveil aren't inherited. So you can use a helper process for opening files.
notaplumber 7y ago
If a program needs arbitrary file-access late or "forever" then at least unveil(2) won't work, because that process needs arbitrary access. Sometimes a user policy can be enforced, i.e: documents must be in $HOME/Documents. But if not, that process can still pledge rpath or wpath. It's broader but may still limit creating/removing files, reading but not writing, etc. unveil(2) requires upfront knowledge, hard-coded or via configuration file, or computed at initialization time before the final locking unveil call. One model is using a privilege separation, various ways to do it, browsers might allow the main browser process access to the filesystem, defining an IPC mechanism (passing file descriptors) for restricted processes, like the renderer or content processes which are "sandboxed". They could use unveil(2) to lock down direct access to the filesystem, except to maybe read access to browser config, temporary directories. Another is having an out-of-process "filepicker" UI.

q3k 7y ago

IIUC, you would usually have a separate subprocess responsible for file access only, communicating over IPC with a less trusted and more complex process (eg. one that parses documents and renders fonts). See: architecture of acme-client(1): https://kristaps.bsd.lv/acme-client/ https://kristaps.bsd.lv/acme-client/

the8472 7y ago

Pledge and unveil aren't inherited. So you can use a helper process for opening files.

notaplumber 7y ago

If a program needs arbitrary file-access late or "forever" then at least unveil(2) won't work, because that process needs arbitrary access. Sometimes a user policy can be enforced, i.e: documents must be in $HOME/Documents. But if not, that process can still pledge rpath or wpath. It's broader but may still limit creating/removing files, reading but not writing, etc. unveil(2) requires upfront knowledge, hard-coded or via configuration file, or computed at initialization time before the final locking unveil call. One model is using a privilege separation, various ways to do it, browsers might allow the main browser process access to the filesystem, defining an IPC mechanism (passing file descriptors) for restricted processes, like the renderer or content processes which are "sandboxed". They could use unveil(2) to lock down direct access to the filesystem, except to maybe read access to browser config, temporary directories. Another is having an out-of-process "filepicker" UI.