Exactly, if we tell you files you create will get nuked, I don’t see an issue of them being nuked if you’ve been told.
Also from SOX compliance purposes, don’t forget mode selection is voluntary, so an attacker can still switch the mode and cause damage.
Correct. My plan for this right now is to have the config files owned and writable by root only and introduce the “untrusted device” feature on folders. The middle layer would not accept any index updates from the lower folders that are not supposed to push changes upstream. If somebody manages to get root privileges, then we’re screwed anyway. But at least we could prevent somebody from changing the folder type and being able to push something upstream. Yes, that specific location would be compromised, but the other 1199 are fine.
In which case it doesn’t seem you’d benefit much from syncthing to start with, as you don’t really have a mesh at the bottom layer as you only connect to the 4 devices in the middle layer.
At this point in time, the 1200 locations are not allowed to communicate with each other. This is something we’re trying to get changed, but it’s a long and painful process (technically it’s easy, politically it’s a nightmare).
I have to disagree with not benefiting from syncthing much. I do believe it solves a lot of our problems. We were looking at using something like opensource bitorrent clients initially, but syncthing adds a lot of security features I’ve been missing with many of the other tools. That’s why I keep pushing on these features. I think it’s almost a perfect fit and I see more potential use cases for us going forward.
I think that a basic torrent tracker with some tooling around it would work better in your chase
The ones I found when I was researching, didn’t satisfy our security and audit departments. That’s how I ended up with Syncthing.
It sounds more and more like you’d really want some sort of not-really-Syncthing tool on those boxes, say a “Syncthing Receiver Lite” which does roughly what you describe:
- Connects to one or more source devices
- Always enforces local state == cluster state
- Never announces its files
With appropriate versioning and stuff it could even be a valid backup destination sort of tool, which Syncthing otherwise isn’t super well suited for.
Anyway, I hear your use case, @Heiko. I get that people want this, and that it’s annoying to keep telling people they are wrong when they want it, @AudriusButkevicius. It’s great to give people what they want. But if it’s something fundamentally unsafe (like the other examples of improving speed by disabling crypto or content hashing) I’m very biased against it.
Perhaps this can be solved by making the UI obvious, foolproof and excellent. I’m certainly open for suggestions. But do keep in mind people in general are already fairly confused by the “master” stuff and we’ve failed to make it crystal clear what that even means. Having another option “mirror” or “receiver” or whatever (it’s not going to be called “slave”) that someone can just enable to see what it does and poof goes their files is definitely not going to fly.
Would your definition of mirror, plus advanced option to nuke stuff fly?
1 Like
Just a thought from a non-programmer.
Would it be possible to display a dialog on the ‘mirror’ machine any time a user attempts to modify the contents of the folder, with a statement along the lines:
"Warning. This folder is under the control of Syncthing and is designated as a mirror folder. As such no changes are permitted by the user.
- added files will be deleted
- modified files will be over-written, and
- deleted files will be restored"
Obviously this would only help in the case of manually initiated changes though.
No, this is not possible
@calmh, I hear your concerns. I think it’s a bit unfair to compare plain stupid requests, like turning off security, with a feature that will nuke unwanted files automatically per the users request. Anyway, I don’t want to be (too) whiny… 
How about this as a compromise: We introduce a new folder type wofolder. Obviously we need to decide on an appropriate name (should we rename everything to Pull & Push, Pull Only, Push Only???). The wofolder type gets another (advanced?) boolean flag, which the user specifically has to enable: DeleteLocalChanges. This way we get the pull only feature, in addition to a delete feature that specifically has to be enabled. Versioning and sync conflicts will of course work also.
1 Like
For my initial need, you are correct. Unfortunately this is not the case for what we need a couple of months down the road. We’ll also have to start pushing files back to the corporate data center. (I’m intending to use a separate folder for that).
Since I didn’t hear anything back and had some time, I went ahead and implemented the changes we suggested. I did not touch the name of the folder type yet.
Here’s the latest diff.
@calmh & @AudriusButkevicius ,
Any feedback from you on the latest approach? Is this something that’s (more) acceptable? I don’t want to waste your time with pull requests, until we come to an agreement.
So I am all in on having the feature, but its @calmh’s playground so he makes the final call.
The PR looks more or less sane, I do have a few style comments etc, but there is no actual PR to comment on. Tests would be nice (potentially integration tests in the test folder), and moving this whole logic out of the model would be awesome too, but as far as i understand @calmh is fine to let that fly.
I think doing what you proposed, a write only-ish folder that is somewhat safe by default but can be set in psychotic mode by an advanced config, would be ok.
File the PR so we can talk about the code.
Another point though. Restoring a deleted file requires re-downloading it. This seems inefficient, so you starting thinking about having Syncthing locally cache files for the write only folder type, perhaps reuse from inside .stversions or have an .stcache or something.
At which point I wonder, why not just have Syncthing sync files to a locked down folder, which can never be changed externally, and have another program instantly apply changes from there to the real location. You gain a local cache, faster reaction time as the files are always available locally, and don’t need to modify syncthing.
The external program could be something neat that auto-nukes changes based on fsnotify subscriptions, or something primitive like while true ; do rsync -va --delete ... ; sleep 10 ; done since this is all local.
What do you want me to call the folder type in the UI? It’s still “Slave” in my code.
I’ll submit the PR as-is, so we have something to talk about.
I haven’t gotten a chance yet to look at how to test this and provide documentation updates. I’ll be travelling, so this part will have to wait a week or two before I get to it.
Cool. Not sure about the terminology, take a read through this: https://github.com/syncthing/syncthing/issues/2679
Perhaps now is the time to fix that.