-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Permission Management
As most of SynoCommunity applications are content-related, and Synology DSM may be used in shared context with multiple users, security improvements have been implemented with DSM 6 support.
Before DSM 6 support, all SynoCommunity applications were granted users
group
membership, allowing them to provide content to any regular DSM users or to any
other applications.
As a result, there was no way to prevent access to sensible application specific folders, and users may access any content or damage application files too.
Some technical or protocol applications accessible from network also has access
to any content readable to users
group even if not necessary, increasing risk
of file leaking in case of security hole or misconfiguration.
SynoCommunity packages take benefits of Synology SDK and DSM 6 support to run
services as non-privileged user account instead of root
. Such account is not
manageable with DSM Control Panel Users and Groups and is not member of users
group.
Access to content is controlled thanks to sc-download
group ACL permissions.
-
Technical or protocol applications has no group membership, preventing access to publicly accessible content.
-
"Producer" application like downloaders are configured to write in dedicated folders (located necessarily in an ACL-enabled Shared Folder) which is configured with
sc-download
group permission. -
"Consumer" application like indexer, media reader... can read folders thanks to
sc-download
group permission (orsc-media
, refer to application specific documentation/FAQ).
With DSM 7 we can't support the above group concept any more, so we need to migrate to the "System internal user". Please follow the instructions below. Once done you can remove the old sc-download
and sc-media
groups.
- Open DSM Control Panel, Shared Folder
- Edit Shared Folder, open "Permissions" tab and select "System internal user" view
- Select either "Read only" on "Read/Write" for package user e.g.
sc-jellyfin
Validate with OK.
In DSM File Station, select target folder, open "Properties" with right click.
In "Permissions" properties, Create a new permission with System internal user for the package e.g. sc-jellyfin
with all Read rights and if relevant Write rights.
For any parent folder, up to Shared Folder root, add a permission with "Traverse folders" and "List folders" in mode "Apply To": "This Folder". If you have a deep folder hierarchy you can set "Apply to this folder, sub-folders and files:" option, it will apply the settings recursively for you.
For more details, please refer to Synology documentation: How to manage ACL settings
SynoCommunity packages now require ACL support to access DSM Shared Folders. ACL is a file system permission management concept which is not limited to "Windows ACL" or "Samba / CIFS remote access".
Please do not try to "workaround" pointing application folders to Linux root file systems instead of Shared Folder locations.
For Share Folder created with DSM version before DSM 5, it is required to convert file system to support ACL.
If Action "Convert to Windows ACL" is available for your Share Folder and you
expect SynoCommunity applications to access them, then proceed with conversion
wizard before granting permissions to sc-download
group.
- Home
-
Packages
- Adminer
- Aria2
- Beets
- BicBucStriim
- Borgmatic
- cloudflared
- Comskip
- Debian Chroot
- Deluge
- Duplicity
- dnscrypt-proxy
- FFmpeg
- FFsync
- Flexget
- Gstreamer
- Google Authenticator
- Home Assistant Core
- Jellyfin
- Kiwix
- [matrix] Synapse homeserver
- MinIO
- Mono
- Mosh
- Mosquitto
- Node-Exporter
- Radarr/Sonarr/Lidarr/Jackett
- SaltStack
- SickBeard Custom
- SynoCLI-Disk
- SynoCLI-Devel
- SynoCLI-File
- SynoCLI-Kernel
- SynoCLI-Misc.
- SynoCLI-Monitor
- SynoCLI-NET
- Synogear
- Concepts
- Development
- Resources