The error path after bw.Flush() failed referenced fd.Close without calling it, so the descriptor was not closed when flush failed.
Signed-off-by: Weixie Cui <cuiweixie@gmail.com>
chore(sqlite): reduce max open connections, keep them open permanently (fixes#10592)
Reduces connection churn, possibly tickling concurrency bug on Windows.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
fix(systemd): Add back chown allowed syscalls
IFF the user enables the `syncOwnership` feature AND sets
`AmbientCapabilities=CAP_CHOWN CAP_FOWNER` as the docs in
https://docs.syncthing.net/users/autostart.html#permissions state,
THEN syncthing needs to use the `chown` syscall.
PR #10421 added a comprehensive sandbox that breaks `syncOwnership`.
In PR #10602 we fixed one part, which is expanding the default
`CapabilityBoundingSet` (see the PR for details).
But there's a very subtle bug that this PR fixes. PR #10421 sets the
following properties:
SystemCallFilter=@system-service
SystemCallFilter=~@privileged io_uring_enter io_uring_register io_uring_setup
(Systemd merges `SystemCallFilter` values; we had to set the property
twice because to negate syscalls, the whole list has to start with `~`.)
The goal was to allow all syscalls in the `@system-service` set, BUT
disallow any `@privileged` syscalls and the `io_uring*` syscalls.
But the sets are not disjoint; `chown` is in both `@system-service` and
in `@privileged`, so it is removed from the allow list by the second
property value.
This property is also parsed in a very peculiar way. From systemd docs:
> If you specify both types of this option (i.e. allow-listing and
> deny-listing), the first encountered will take precedence and will
> dictate the default action (termination or approval of a system call).
> Then the next occurrences of this option will add or delete the listed
> system calls from the set of the filtered system calls, depending of its
> type and the default action. (For example, if you have started with an
> allow list rule for read() and write(), and right after it add a deny
> list rule for write(), then write() will be removed from the set.)
Not only does the order of `SystemCallFilter` properties matter (later
ones can undo effects of prior ones), but the _type_ of the _first_
property sets the overall behavior of the syscall filter: if the first
`SystemCallFilter` value is an allow list, then all syscalls that are
not specified are disallowed by default (and reverse if the first value
is a deny list).
Of course, this is completely different from how other allow/deny lists
are implemented in systemd; for example, `IPAddress[Allow|Deny]`
properties don't work like this at all. >:(
Since this complexity has bit us once, we're removing the additional
deny list of syscalls and sticking with just
`SystemCallFilter=@system-service`.
This leaves some privileged syscalls in the allow list. Other options
would require entering the "deny list by default" mode and deny lists
are less secure than allow lists in general because they have to be
maintained (the kernel always adds new syscalls). The rest of the
sandbox (capability bounds) should be sufficient.
Fixes#10603
Signed-off-by: Val Markovic <val@markovic.io>
Syncthing docs in https://docs.syncthing.net/users/autostart.html#permissions
tell the user to set `AmbientCapabilities=CAP_CHOWN CAP_FOWNER` if the
user wishes to use the `syncOwnership` option.
https://github.com/syncthing/syncthing/pull/10421 broke `syncOwnership`
for users that followed that advice because the PR introduced
`CapabilityBoundingSet=` which cancels out any additional capabilities
granted with `AmbientCapabilities`.
(`AmbientCapabilities` _adds_ capabilities; `CapabilityBoundingSet`
_limits_ maximum capabilities to the specified set. Setting
`CapabilityBoundingSet` to an empty list prevents any capabilities from
being acquired in any way.)
This PR fixes the breakage by explicitly setting
CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER
This does _not_ grant any additional access rights to syncthing if the
user is not explicitly setting `AmbientCapabilities` as well, but it
does loosen the sandbox _a bit_. An attacker compromising the syncthing
process could now more easily expand their access to include
CAP_CHOWN/CAP_FOWNER even if the user is not setting
`AmbientCapabilities`.
Signed-off-by: Val Markovic <val@markovic.io>
Update the existing minimal service hardening with a comprehensive
sandbox to minimize blast damage from service compromise.
Please see the detailed code comments for an explanation of what is
sandboxed.
Roughly, we limit: /dev, /proc, /tmp, AF_UNIX, AF_PACKET, execution of
_any_ binary other than "/usr/bin/syncthing" and "/usr/lib",
uncommon syscalls plus io_uring, tons of kernel internals and more. We
also enable a bunch of kernel namespaces for isolation.
In short, pretty much everything is sandboxed and specifically tuned for
syncthing's behavior.
Sadly, we cannot use ProtectSystem=strict by default because we don't
know the directories that the user will be sharing. There's a big
comment block explaining how users can enable it for "extra credit". :)
If the user did add the following options as the unit file recommends:
- ProtectSystem=strict
- ReadWritePaths=/my/shared/dir1 /my/shared/dir2
- ProtectHome=true
Then the user would end up with a *far* more comprehensive sandbox than
anything a container runtime (like Docker/Podman/whatever) would
provide.
Much (but not all) of these options could be ported to the
user/syncthing.service file, BUT it would require work. Systemd does not
allow all of these options to be used with the user service manager,
although using PrivateUsers=true would help with most of it.
I cannot justify the time investment to develop, audit and test the
port to user/syncthing.service so I leave that for interested
contributors.
Tested on Debian Trixie (13) with the following versions:
- v1.29.5, Linux (64-bit Intel/AMD)
- latest HEAD (d3d3fc2d0 committed on Mon Oct 6 01:42:58 2025)
Signed-off-by: Val Markovic <val@markovic.io>
Also adds a method to query the last database maintenance time.
Signed-off-by: Tommy van der Vorst <tommy@pixelspark.nl>
Co-authored-by: Jakob Borg <jakob@kastelo.net>
The css and svg files have license headers, but there were no separate
license files like the other vendored assets in `gui/default/vendor/*`.
This issue came up while we were working on updating and modernizing the
syncthing package in Fedora Linux.
This commit copies the existing license headers into separate files
to make things easier for license scanning and SCA tools,
such as [Go Vendor Tools](https://fedora.gitlab.io/sigs/go/go-vendor-tools/).
* [...]/css/LICENSE.txt is copied from the license header in
gui/default/vendor/fork-awesome/css/fork-awesome.css.
* [...]/fonts/LICENSE.txt is copied from the license text in the
<metadata> tag of
gui/default/vendor/fork-awesome/fonts/forkawesome-webfont.svg.
Relates: https://src.fedoraproject.org/rpms/syncthing/pull-request/4
Signed-off-by: Maxwell G <maxwell@gtmx.me>
This change allows the periodic database maintenance to be disabled, while providing a way to programmatically start maintenance at a convenient moment.
Signed-off-by: Tommy van der Vorst <tommy@pixelspark.nl>
dageckoandGitHub
Jakob BorgandGitHub
Syncthing Release Automation
bt90andGitHub
cuiandGitHub
Val MarkovicandGitHub
Michael Wang 汪東陽andGitHub
Shivam KumarandGitHub
Maxwell GandGitHub
Prathik P KulkarniandGitHub