Does this work everywhere Syncthing currently runs as a systemd service?

It should. Systemd only works on Linux and nothing in this PR is distro specific. It should work on any Linux distro that uses systemd.

It should even work on older versions of systemd that don't support some of these options; they will be ignored (with possibly a warning printed in the journal).

If systemd supports the option but the kernel does not (for whatever reason), systemd will ignore the option. Thus the sandbox is "best effort", as the systemd docs recommend it be used.

Also, none of these options introduce external dependencies. These are all pure systemd+kernel features (ignored when not supported, as mentioned).

I pushed f48a680 which removes NoExecPaths from the default set of sandboxing options. It's now documented in the "extra credit" section.

Advice for maintainers: since this now makes it possible for an attacker to escalate access to the rest of the system by calling other binaries already present (LOTL), it would be prudent to use internal app sandboxing to limit which binaries syncthing is capable of executing.

For instance, it would be a great idea for syncthing code to sandbox the syncthing process so that it can only execute allow-listed binaries like syncthing, /usr/lib and the binaries the user provided in the config for the External File Versioning feature.

Setting up the necessary custom mount namespacing is a non-trivial amount of work though. But there are sandboxing libraries that can help with this. Tough sell, I know.

I have already been using most of these for some time, but sadly never found the time to contribute something similar, so kudos. I've added in those I wasn't using and will feedback if I have any problems.

I've made a small tweak to prevent a systemd warning about io_uring_enter2 (code comments have details). I've also tightened the umask so it's 7027, which now also prevents creation of files with setuid/setgid bits which are designed for privilege escalation. Such files are incredibly dangerous.

@ProactiveServices Any further comments?
@calmh Any chance of this being merged in the foreseeable future? Or should I drop it?

I don't really use the systemd setup much and can't vouch for or maintain this, so I'd like someone else to step up and say they've tested it, that it won't cause any problems for the users already using it on upgrade, and that they'll make sure it works for future versions.

I don't understand the hate for io_uring. Google is mostly having problems with older LTS kernels and many people are judging based on inflated CVE numbers. The kernel developers fixed the thread model in version 5.10, solving the most fundamental problems. I'm not saying that there won't be any future issues, but it's fine if you're not a cloud service provider 🤷

(Apologies for the delays, I'm down with COVID. I'll respond to comments when I've recovered.)

@CoelacanthusHex I added a note about AF_NETLINK, thanks!
@marbens-arch Good point, I added AF_UNIX to allowed list! The web UI does not listen on a UNIX socket by default, but the docs explicitly state this is supported so it should continue to work.

I want to thank both of you for leaving comments because it pinged me and made me realize I had, uh, forgotten about this PR. 😅

@ProactiveServices I don't see the error message we both noticed (Supervising process 55825 which is not our child. We'll most likely not notice when it exits.) in my logs anymore:

Jan 29 12:05:39 vault systemd[1]: Starting syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing...
Jan 29 12:05:39 vault systemd[1]: Started syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing.
Jan 29 12:05:39 vault syncthing[2723]: [start] INFO: syncthing v1.29.5 "Gold Grasshopper" (go1.24.2 linux-amd64) debian@debian 2025-04-20 21:21:27 UTC
Jan 29 12:05:39 vault syncthing[2723]: [EYBZ4] INFO: My ID: <redacted>
Jan 29 12:05:39 vault syncthing[2723]: [EYBZ4] INFO: Hashing performance is 232.15 MB/s
Jan 29 12:05:39 vault syncthing[2723]: [EYBZ4] INFO: Overall send rate is unlimited, receive rate is unlimited

@calmh @ProactiveServices I'd be happy to mantain this service file going forward. I've been using syncthing for many years now and I have no intention to stop using it. I exclusively use the systemd service file on my servers. If there are any issues, an at-valloric ping on Github should reliably reach me.

Meanwhile, I've been using this sandboxed setup for several months now across several devices with zero issues. I think the PR is ready to merge.

@calmh

so I'd like someone else to step up and say they've tested it, that it won't cause any problems for the users already using it on upgrade, and that they'll make sure it works for future versions.

As mentioned, I've extensively tested this on my systems. This sandbox has been designed to be as widely applicable as possible. I of course cannot promise the absence of bugs or upgrading issues; people have all sorts of weird configurations. What I can commit to is fixing any reasonable¹ problems people bring up after upgrading.

Just an FYI that this PR was my "this change broke my workflow" moment (https://xkcd.com/1172/). "Silently" changing the umask wasn't that awesome for me. I relied on having some files world-readable on a folder so that folder had "ignore permissions" enabled in order for syncthing to rely on the umask (instead of whatever permissions the other side uses), but with this new default you can't even stat the dir if you're not the owner. For folders where permissions are synced the umask doesn't matter anyway, but this is a rather significant change in permissions for all folders where ignore permissions is set.

(systemd override obviously fixed it, just a surprising behaviour change given that this was released as a minor patch)

@GermanCoding I'm sorry this change affected your workflow, but a world-readable umask for a folder containing unknown PII is not a safe default. If you need it, you should set it explicitly in a systemd unit override (as you've discovered).

These changes broke the "inherit ownership" setting. To get it working again, I had to override the sandbox configuration to allow access to the chmod system call.

### Editing /etc/systemd/system/syncthing@admin.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
AmbientCapabilities=CAP_CHOWN CAP_FOWNER
CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER
SystemCallFilter=@system-service chmod

### Edits below this comment will be discarded

Thank you for the contribution though; this looks like a good change.

@calmh Thoughts on the CAP_CHOWN/CAP_FOWNER above? These Linux capabilities give very broad powers to the syncthing process that could be easily used for privilege escalation attacks. CAP_CHOWN allows for "arbitrary changes to file UIDs and GIDs" and CAP_FOWNER is even broader.

I don't think a folder syncing service should have the access rights to change/ignore filesystem ownership across the entire OS. These rights cannot be scoped to a folder. I'm not sure what this "inherit ownership" setting is though, but IMO it cannot be worth this level of access.

WDYT? I'm wary of breaking existing functionality. Can we "solve" this with better documentation? Maybe something like "users wishing to use 'inherit ownership' on Linux will need to add the following properties to a systemd override file while keeping in mind the security exposure".

It requires what it requires. These capabilities weren't default earlier either and just need the proper docs to enable.

IMO it cannot be worth this level of access. WDYT?

I don't know what you're suggesting or implying here, but I suspect you need to chill. We're not going to remove features people are using just because you don't like the required capabilities.

@calmh I want to call out that a position of "zero breakage of shipped features" is not unreasonable. If that's the call syncthing maintainers wish to make, I'll carve out the necessary access.

We're not going to remove features people are using

This is fair.

just because you don't like the required capabilities.

This is unnecessary. :) It's not about personal distaste/opinions, it's about user security exposure. CAP_CHOWN/CAP_FOWNER provide significant opportunity for privilege escalation.

These capabilities weren't default earlier either and just need the proper docs to enable.

Now I'm confused... how did this PR then break the "inherit ownership" setting? @agoeckner Could you provide more info on the breakage you saw in an issue report? Please at-tag me in your issue.

Presumably because the previous additions to enable them are no longer enough given the additional sandboxing.

Or they were running the service as root.

Presumably because the previous additions to enable them are no longer enough given the additional sandboxing.

Could you explain "previous additions" more? I'm not sure what you're referring too.

Or they were running the service as root.

This PR changes syncthing@.service, not syncthing.service. I guess it's possible @agoeckner used syncthing@root.service, but that would be a weird setup given that syncthing.service is right there... I'm assuming it's something else. We need more info from @agoeckner to track it down though.

This: https://docs.syncthing.net/users/autostart.html#permissions

This: https://docs.syncthing.net/users/autostart.html#permissions

That makes perfect sense! So this feature always required the user to add extra permissions.

We can fix this retroactively by adding:

AmbientCapabilities=
CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER
SystemCallFilter=@system-service chmod

in syncthing@.service. This results in no increase in permissions for people who aren't already setting AmbientCapabilities=CAP_CHOWN CAP_FOWNER. Setting CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER only sets a "cap" on maximum permissions that could ever be reached; adding capabilities here is not a huge deal (they're not granted, they just become possible to acquire in the future). Likewise, adding chmod to SystemCallFilter doesn't do much by itself because while syncthing can then invoke the syscall, it would just get a "permission denied" without AmbientCapabilities=CAP_CHOWN CAP_FOWNER.

I'll send a PR.

Sent #10602

Hey @Valloric! Sorry, I'm a little bit confused. Are you by chance using an LLM for your responses and PRs? Edit: Sorry, that was pretty rude of me. I totally misunderstood you!

The PR #10602 doesn't actually address what I reported, and it contradicts your previous work, where you had already included the AmbientCapabilities and CapabilityBoundingSet as commented options that the user could enable.

The minimal change required is to add chmod to SystemCallFilter, which allows Syncthing's ownership inheritance feature to work.

I suppose that you could also set the CapabilityBoundingSet to CAP_CHOWN CAP_FOWNER. The user would then only need to set AmbientCapabilities=CAP_CHOWN CAP_FOWNER.

Hey @Valloric! Sorry, I'm a little bit confused. Are you by chance using an LLM for your responses and PRs?

No, I wrote every word in every comment and PR. I despise LLM-speak. Please don't "jump the gun" and accuse people of LLM-speak with zero evidence.

The PR #10602 doesn't actually address what I reported, and it contradicts your previous work, where you had already included the AmbientCapabilities and CapabilityBoundingSet as commented options that the user could enable.

Your report contained very little information. Please provide more information in the future so we don't have to reverse-engineer the issue we think you might have encountered. Consider filing an issue report instead of leaving comments on closed PRs.

I suppose that you could also set the CapabilityBoundingSet to CAP_CHOWN CAP_FOWNER. The user would then only need to set AmbientCapabilities=CAP_CHOWN CAP_FOWNER.

Yes, this is what @calmh and I were guessing were the issue you encountered. CapabilityBoundingSet would have broken any override that sets just AmbientCapabilities, as the docs stated.

The minimal change required is to add chmod to SystemCallFilter, which allows Syncthing's ownership inheritance feature to work.

As the discussion in #10602 pointed out, chmod is already included in @system-service¹ so adding it to SystemCallFilter does absolutely nothing (perhaps it was an LLM hallucination?).² The linked source is direct from systemd.

Did you try out the fix in #10602? Please confirm if the problem persist after those changes are applied.

Sorry, I'm just so used to people putting everything through an LLM. It's a perpetual peeve of mine!

Initially, I only used the override suggested in the systemd unit comments/documentation:

AmbientCapabilities=CAP_CHOWN CAP_FOWNER
CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER

However, the inherit ownership feature did not work until I added the SystemCallFilter override as well:

AmbientCapabilities=CAP_CHOWN CAP_FOWNER
CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER
SystemCallFilter=@system-service chmod

I'm not sure what's going on here. You're right that @system-service should already include it.

I wonder if it's being removed by this line: https://github.com/syncthing/syncthing/pull/10421/changes#diff-9da7d7beb75aa041e0bd9698a0b479b0e769baa8ea50f816dca52f77fd16096fR124
My override would actually have overridden/removed that line too.

edit: Yep, that's the case. chmod is removed by the ~@privileged: https://github.com/systemd/systemd/blob/44b050fe761c579f5b9f7392aacc697ed1311b35/src/shared/seccomp-util.c#L778

edit: Yep, that's the case. chmod is removed by the ~@PRIVILEGED: https://github.com/systemd/systemd/blob/44b050fe761c579f5b9f7392aacc697ed1311b35/src/shared/seccomp-util.c#L778

You might be right! Very surprising behavior from systemd here. Docs:

SystemCallFilter=
           Takes a space-separated list of system call names or system call groups. If this setting
           is used, system calls executed by the unit processes except for the listed ones will
           result in the system call being denied (allow-listing). If the first character of the
           list is "~", the effect is inverted: only the listed system calls will be denied
           (deny-listing). This option may be specified more than once, in which case the filter
           masks are merged. If the empty string is assigned, the filter is reset, all prior
           assignments will have no effect.

So what does "merged" mean then? Does the order of SystemCallFilter declaration matter? What would happen if we listed SystemCallFilter=@system-service second, after SystemCallFilter=~@privileged ...? Should we merge declarations into one SystemCallFilter=, with careful ordering or items in the list?

I'll need to read some systemd source code and experiment, the docs are definitely not clear on this.

@agoeckner Could you file an issue to track this? 😃

Besides the @privileged issue, there's also a mixup of chmod and chown (not disagreeing that it's confusing overall :) ):

Confirmed by looking at the systemd source code: https://github.com/systemd/systemd/blob/44b050fe761c579f5b9f7392aacc697ed1311b35/src/shared/seccomp-util.c#L951

@System-service includes @chown and fchmod (plus variants). I'll remove this.

From here:
https://app.datadoghq.com/monitors/262149163?group=rabbitmq_queue%3Adbuploadersensdb1aws%2Crabbitmq_vhost%3Aunified_stream&from_ts=1773261643000&to_ts=1773262843000&event_id=8539598550854497891&link_source=monitor_notif&link_monitor_id=262149163&link_event_id=8539598550854497891

Comment says it includes fchmod et al, but the linked code only showns chown - chmod is part of @file-system not @system-service. So that might be why we still need it explicitly there - no idea how that interacts with @privileged.

Very true, but @file-system appears to be part of @system-service.

And sure @Valloric let me create one.

Regarding chmod vs chown... Let me double-check which one I actually added to my server's configuration once I get home. Perhaps I made a mistake when reporting my solution :)

New issue created: #10603.

I can also confirm that I did include chmod instead of the correct chown in my filter settings. However, I think what's actually important is that my filter override removed ~@privileged.