[Feature request]: Add write-only permission option for filesystem access

[Integral-Tech]

Checklist

• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

Currently, only :ro and :create is supported in Filesystem access. A write-only permission option is useful in some temporary directories, such as /tmp.

[smcv]

I don't understand why an application would write a file to /tmp if it doesn't want something (perhaps another component of itself) to read back the contents? If the file is truly write-only, what's the point of it existing at all?

[smcv]

Sharing /tmp with the host system is likely to break other programs' assumptions about safe filesystem accesses: a Flatpak app with write access to /tmp is likely to be able to carry out symlink attacks that trick programs in the trusted computing base into overwriting arbitrary files. As a result, --filesystem=/tmp (with or without the write-only option you propose here) should only be given to apps that you completely trust, similar to --filesystem=host.

Flatpak normally gives each application its own private /tmp (an implementation detail is that it is currently $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID/tmp on the host system, although this is not an API guarantee).

[Integral-Tech]

if it doesn't want something (perhaps another component of itself) to read back the contents

For example, files downloaded by a download software, screenshots captured by a screenshot software... They don't need to be read back at all.

[smcv]

Now that I think about it, this is not actually implementable as static filesystem access, because we can mount filesystems read/write or read-only, but the kernel does not give us a way to mount them write-only. So this cannot be a static filesystem access mode that works the same way as the current --filesystem.

In principle it would be possible to implement as a FUSE filesystem or something (more FUSE filesystems, ugh) but it would have to be extra-paranoid about things like symlink attacks: probably it would have to only allow writing to new, unique filenames with O_EXCL. And I think it would be confusing for that to share the --filesystem name: if it is useful enough to justify the implementation effort, then it should likely have a different name.

Portals might be a better fit for this.

files downloaded by a download software

Those are often written to a temporary filename and then renamed to their final name, which requires non-trivial filesystem accesses (and quite possibly read access).

screenshots captured by a screenshot software

Flatpak apps on a Wayland desktop can't take screenshots, except by asking the screenshot portal, which already saves the file to the pictures directory (outside Flatpak's control).

Flatpak apps on an X11 desktop technically can take screenshots because X11 isn't a good security boundary, but they should use the screenshot portal instead.