Rudd-O
December 13, 2021, 6:04am
1
Hi folks.
I wrote the Qubes shared folders service in an afternoon. It is what it is – useful, but not ideal.
I’ve come up with a design for an improved version that I would like you to review for correctness and to see if it could be implemented better. I think this design has potential, and I want your feedback before implementing it.
The document is at qubes-shared-folders/authorization-design.md at master · Rudd-O/qubes-shared-folders · GitHub . Thanks in advance for your feedback.
1 Like
Rudd-O
December 13, 2021, 3:04pm
2
The document has been updated and now lives in branch perfolder:
# Next-gen folder share authorization design
Initially, Qubes shared folders used standard Qubes RPC authentication to decide whether to grant access to the folders of a qube (called *server* in this document) initiated by another qube (called *client* in this document).
This happens through the client qube invoking the `ruddo.ShareFolder` RPC service on the server qube, which if successful causes the `diod` daemon to be started on the server VM and finally connected via file descriptors to the kernel `v9fs` file system module in the client VM.
This is perfectly adequate for the use case where the user wants to grant the client qube blanket read/write access to any folder in the server qube. This is, however, inadequate if the user wants to grant different client qubes finer-grained access to specific subfolders.
Consider, for example, one scenario of a "file server" qube that acts as a repository of data for three other client qubes: `work`, `projectX` and `social`. Our stipulated user may want to save some types of data to some folders in the file server qube, but may not want to mix them. In this scenario, our user wants work data to be saved to `fileserver:/home/user/Work`, social data to be saved to `fileserver:/home/user/Memes`, and his project X (work-related) involves some data that should *also* be accessible to his work qube, but he does not desire to grant the project X workspace access to *all* the work data, so he decides to store project X data under `fileserver:/home/user/Work/projectX`. We further stipulate in this scenario that shuttling files around manually using the `qvm-move` facilities would severely impede the user's enjoyment of the Qubes system he is running.
This setup naturally requires a more sophisticated access control mechanism than a simple yes/no policy decision.
# User interaction
What we propose is the following:
1. The user instructs the client qube to mount folder `X` on the server qube.
2. dom0 asks the user "client qube wants to mount folder `X` on server qube".
3. The user responds accordingly. If authorized, the connection is permitted and the client qube can successfully mount `X`.
show original
It already contains an implementation, which should be reviewed, of the feature.
