On 3/11/25 19:28, Mickaël Salaün wrote:
On Mon, Mar 10, 2025 at 12:39:04AM +0000, Tingmao Wang wrote:
On 3/6/25 03:05, Tingmao Wang wrote:
[...]
This is also motivated by the potential UX I'm thinking of. For example,
if a newly installed application tries to create ~/.app-name, it will be
much more reassuring and convenient to the user if we can show something
like
[program] wants to mkdir ~/.app-name. Allow this and future
access to the new directory?
rather than just "[program] wants to mkdir under ~". (The "Allow this
and future access to the new directory" bit is made possible by the
supervisor knowing the name of the file/directory being created, and can
remember them / write them out to a persistent profile etc)
Another significant motivation, which I forgot to mention, is to auto-grant
access to newly created files/sockets etc under things like /tmp,
$XDG_RUNTIME_DIR, or ~/Downloads.
What do you mean? What is not currently possible?
It is not currently possible with landlock to say "I will allow this
application access to create and open new file/folders under this
directory, change or delete the files it creates, but not touch any
existing files". Landlock supervisor can make this possible (keeping
track via its own state to allow future requests on the new file, or
modifying the domain if we support that), but for that the supervisor
has to know what file the application tried to create, hence motivating
sending filename.
(I can see this kind of policy being applied to dirs like /tmp or my
Downloads folder. $XDG_RUNTIME_DIR is also a sensible place for this
behaviour due to the common pattern of creating a lock/pid file/socket
there, although on second thought a GUI sandbox probably will want to
create a private copy of that dir anyway for each app, to do dbus
filtering etc)
