There have been several posts in this direction. Let me tell you what I’m doing and where I’m trying to go. What I want to do is a form of file sharing between FreedomBox applications and my phone.
Requirements
- I want my photos I take on my phone to be copied from the phone to FreedomBox.
- I want the photo on FreedomBox to get imported into zoph, or at least be importable through the zoph web UI.
- I want the original copy of the photo on the phone to be deleted once the photo is available through zoph.
- I don’t want to have to worry about leaving too many photos around in my phone hogging up the storage and forcing me to deal with them there.
- If I want to get a photo I’ve taken on my phone, I’ll go to zoph and work with it from there.
- I don’t want the “free” cloud host to complain that I’m using too much storage and my service is being throttled or curtailed.
I think some other posts are similar use cases to mine:
- putting torrent files in a samba share
- synchronizing samba share to client with syncthing
- a person looking at FreedomBox to replace google photos paid storage # motivation for this post
There are more, but it’s all kind of the same sort of thing: how do we make our file go through a workflow where different FreedomBox apps are involved?
Opportunity Statement
- FreedomBox wisely uses privilege separation between apps.
a) A file created by serviceA is usually owned by user:group of serviceA:serviceA (such as syncthing:syncthing) - There is a valuable workflow which would hand off files from serviceA to serviceB
- In order to create this workflow we need to allow serviceB access to the content created/managed/owned by serviceA.
- An ordinary user (a personal account, not root or a service account) should effect the file operation either manually or through scripted operation using their own login and uid (user ID).
- It may be necessary to set this up with elevated privileges, but having done so correctly the workflow can then be made by the user.
- The other contents of the FreedomBox system are protected in the expected fashion - user only gets the necessary permission for the job.
- If we get this right, we may be able to develop a specification which could be built into FreedomBox for this purpose making the product more valuable.
Filesystem permissions alone don’t get the job done.
I added myself to the syncthing group and the zoph group. I can copy a file from syncthing into the zoph/upload directory, but even so I cannot import the file in zoph because ‘joseph’ owns the file, and zoph will be unable to delete that file from upload during the import process causing the import to fail.
“Hard” links don’t work for this.
A hard link is an additional filename and path to a file.
- This does not duplicate the content - which is nice
- Both links must be on the same filesystem - somewhat inflexible
- The file metadata (user, group, permission) cannot be different for each filename - this is a stopper.
ACL (Access Control List) may be a way.
ACL is an rich, extended file permissions scheme which goes beyond the basic UX user:group permission model. Let’s flesh out the details of the example job:
- /var/lib/syncthing/DCIM/IMG_123456.jpg needs to be moved to /var/lib/zoph/upload
The operations we need to allow for this to take place are:
- user needs to read the content of syncthing/DCIM to see the files in the syncthing managed DCIM directory.
- user needs to write the content of syncthing/DCIM to change the contents of the directory (delete a file)
- user needs to read the content of syncthing/DCIM/IMG_123456.jpg to create a new copy of the file
- user needs to write (delete) the syncthing/DCIM/IMG_123456.jpg file at the end of the file move
mvoperation. - user needs to write to the zoph/upload directory to add a file to the directory and update its contents.
- www-data:zoph user/group needs to be able to read and delete the file in the upload folder to complete importation.
- there are some other steps we should tackle in the future to prevent one user from deleting another user’s uploaded photo and suchlike.
We can use getfacl to show us the ACL on the syncthing/DCIM folder…
$getfacl DCIM
# file: DCIM
# owner: syncthing
# group: syncthing
user::rwx
group::r-x
other::r-x
Now let’s try setfacl to add rwx permission for user ‘joseph’. We’ll need sudo for this permission change to a directory not owned by the user.
sudo setfacl -m user:joseph:rwx /var/lib/syncthing/DCIM
Now check ACL again…
$getfacl DCIM
# file: DCIM
# owner: syncthing
# group: syncthing
user::rwx
user:joseph:rwx
group::r-x
mask::rwx
other::r-x
Nice! user:joseph:rwx means read/write/execute for the folder. This will allow mv to read a file from DCIM and then delete the file at the end of the mv operation.
On the zoph/upload side joseph:zoph will create a file. Then www-data:zoph will read and delete the file.
sudo setfacl -m user:joseph:rwx /var/lib/zoph/upload
… and then the zoph program user www-data:zoph will read the file from upload and delete it after completing the upload.
setfacl -m user:www-data:rwx /var/lib/zoph/upload/IMG_20240925_083357.jpg
Note that setfacl doesn’t require sudo this time because user joseph already owns the file IMG_20240925_083357.jpg and ACL permissions are the file owner’s to give to whom they choose.
zoph imports the file without complaints.
NEXT STEPS
A summary of what this means.
- A user who owns a syncthing share can be given direct access to this share on FreedomBox using their ordinary user account. Please be careful! We could also apply this to a subdirectory of the syncthing share where this would be prudent.
A more usable explanation steps to follow to enable a similar operations. A good explanation of risks and design so determined users don’t mistakenly overpermit file operations and then make a data-losing mistake.
A better basic design in this post to create a minimum permission set to get the job done. Making everything rwx isn’t the best way to do this. Other users still need their content protected.
This also opens the door to bigger use cases such as, "I want to open a photo in zoph with gimp and edit the file in place. It seems like you could get there from here with some mix of samba, zoph, and ACL followed by thumbnail regeneration by zoph.