In Heartbeat, the introducer server that allows people to find each other has shared folders with everyone which it uses to relay messages between people who have not become friends yet. (And to relay messages when adding a new device to your list of devices.) We don’t necessarily trust everyone to be outstanding citizens. They could try a denial of service attack by filling up the message folder that is from them to us with huge files.
This will also be helpful even for repositories between trusted parties (friends) as it will stop mistakenly shared files (that are dropped into the wrong folder on the file system) and perhaps future repositories that are limited by file type/MIME type.
So, in summary: support for repositories where you can limit on:
I probably could perform an even better DoS attack by filling up a folder with millions of tiny files (or even better, empty files) bloating the index…
So I am not sure limiting by file size nor by file type prevents DoS?
Plus, these limits would be on an individual basis… so everyone should set the limits in order for them to work properly.
I am not sure how Heartbeat works underneath to understand what exactly you are trying to achieve… but I assume it creates two folders per relation, each being the inbox of the other user?
I could see a folder quota being useful though. “If the size of this folder exceeds x MB, don’t try to pull any more files from the cluster.” I’d actually use that for some of our work shares, setting a limit of 5 GB or so when the expected amount of data is like 250 MB, just to guard against someone dropping a VM image in there that I don’t want.
This may be a bit of a topic hijack but I would love to start a discussion about whether it makes sense to think about alternate/finer-grained permission models for Syncthing.
I think that having a more sophisticated permissions model than just R/W and R/O makes the management of public/semi-public shares much easier and may even open up new use cases that haven’t been considered yet.
So, for an example, I would love to have a semi-public media share for my house. People could link their personal media collections to one large NAS accessible from the house media devices. With the current permissions models, this is problematic. I have two computers that I am currently syncing and I am liable to add or change media from either of them. However, I do not want any deletions or other modifications made on the public share to propagate back to my computers.
As I understand ST’s current permissions models, the only way to protect my two personal copies of the shares is to make them master nodes. However, this prevents changes on my nodes from propagating to each other.
Further, even if ST has R/W and R/O model public shares, some things are still quite tricky. Let’s say that the house has a single large media share that everyone is synced to. We may want to have all the files in one root media directory, a first subdirectory layer by genre, a second layer by artist and then subdirectories by album/movie. I may have one Johnny Cash album and my housemate has another. This means that everyone’s media is now interleaved across a directory tree and intermingled. Even if we assume that each individual movie or album directory is owned by a different user, there is no way to control access unless hundreds or thousands of individual shares are made. I use this example since it is the exact file structure my house is currently using and would like to continue using.
I’ve been thinking about permissions models for the last few days and two different ones (which are not necessarily mutually exclusive) come to mind:
A replication of the linux permissions model. The files in ST shares are given ownership. The initial node that provides the files retains ownership and can also share/transfer ownership or each file with other nodes. The owners of files can specify (on a per share basis) the R/W or R/O nature of those files. In the previous example, I can share my Johnny Cash directory and files to a larger share but specify that they are R/O to non-owners. Now, I can modify or delete that specific directory but my housemates cannot. Likewise, if they do the same setup, I can read and copy their files but not modify them even those all of these directories are in a single ST share. I haven’t had a chance to look at the ST code closely enough to get a feel for whether this would require an excessive amount of overhead on top of the existing protocol.
Another idea is something similar to a CRUD model rather than a simple R/W, R/O model. (CRUD being Create/Read/Update/Delete) For the example above, I could set up a share where everyone only has Create and Read access. The NAS node would have full CRUD access and so if something needs to be deleted, I can just SSH in and manually tweak the share. Compared to the ownership model, this is a lot less flexible but it seems like it would be easier to implement.
Both of these models would work well together. Being able to share multiple users’ files in a single share and allowing each user to control the CRUD access of others to those files would make ST much more flexible.
With Pulse coming, it seems that ST is going be be more of an engine in the long run rather than a standalone application. If ST keeps a simple R/W, R/O permissions model, it’s going to remain mostly limited to file backup type utilities. However, if it’s made to be very flexible and fine-grained, I can see it being the back end for a diverse range of applications such as team coordination tools, real-time collaboration applications, etc.