I've been running Channels on a Synology NAS via the native package for over a year, and it works great. But I just noticed Channels is also available as a Docker image. I'm curious - Is there any advantage of one over the other?
It's more secure. The package is running with root privileges, which is definitely not a good thing 
I asked whether they planned to fix this some day and, IIRC, was told they mean to. Fixing it, in and of itself, probably won't be the big challenge. It's updating existing installations cleanly that'll be the challenge because of things like this:
$ ls -l /volume1/channels-dvr
total 0
drwxrwxrwx+ 1 channels-dvr users 1320 Mar 27 15:43 Database
drwxrwxrwx+ 1 root root 8 Feb 3 10:10 @eaDir
drwxrwxrwx+ 1 channels-dvr users 8768 Mar 27 13:30 Images
drwxrwxrwx+ 1 channels-dvr users 32 Jul 25 2019 Logs
drwxrwxrwx+ 1 root root 38 Aug 6 2018 #recycle
drwxrwxrwx+ 1 channels-dvr users 18 Jan 29 12:19 Streaming
drwxrwxrwx+ 1 channels-dvr users 1820 Mar 23 19:47 TV
Even in the directories owned by channels-dvr, everything is owned by root:root. Any upgrade script would have to recursively scan all those directories and fix the ownerships. <does a double-take...> Oh boy, I just realized it's worse than I thought: The permissions on everything in there is world writable.
Let me put it to you this way: You really don't want to run or store anything of value on a Synology NAS running Channels outside of Docker, because Channels DVR on a Synology NAS is a world-class security nightmare in its current form.
I love the product and the devs are great guys, but this aspect of the package is really, really poor
1 Like
I agree about the security and root user on the native Synology install.
I also wish they could fix it to run as another user.
Not sure how you got those permissions?
I had the Channels DVR install create the ChannelsDVR directory in my shared folder /volume1/arkives and this is what I see on my Synology NAS.
ls -l /volume1/arkives/ChannelsDVR
total 20
d---------+ 25 root root 4096 Mar 27 15:26 Database
d---------+ 3 root root 4096 Mar 7 15:16 Images
d---------+ 4 root root 4096 Mar 7 14:03 Logs
d---------+ 3 root root 4096 Mar 8 17:51 Streaming
d---------+ 2 root root 4096 Mar 27 11:00 TV
Maybe because you setup the directory to use the Synology recycle bin (I didn't)?
So the consensus is that the Docker installation is more secure? Any other advantages/disadvantages?
Ah. No. Probably because I tried to import the channels-dvr stuff I'd had running on our home network server as a test.
I wanted to run it on my Linux box to evaluate it. I installed the package, ran it, saw what was going on, and said "No flippin' way." Figured out where it put stuff, shut it back down. Created "channels" users and groups, set the channels-dvr binaries to suid:sgid channels:channels, changed all its installation and data directories to owner:group channels:channels, and started 'er back up. Just like that: Secured. As I said: It wouldn't be particularly difficult to fix this problem. Alternatively, probably could have run it in a chroot'd jail. That's a lot trickier, though.
Not that I distrust(ed) the Channels devs intentions or software, but it's just plain bad practice to run code with elevated privileges unless it's system-level code that has to run with elevated privileges. (That, and poorly-designed, poorly-written software is why MS-Windows has historically been the problem it has.) I was not going to run that package the way it was on our trusted home network server.
The NAS has nothing sensitive on it. It never will, until and unless the Channels devs fix the package.
Well, Docker is a bit more secure than just running packages as root. Not all Synology packages work that way, though. SynoCommunity's packages allow packages to run as different users (such as sc-media for their media packages, like Tvheadend, another DVR software.)
However, Docker has many known security issues, too. The advantage, though, is that Docker containers follow the OCI standard, and so they've become the "standard", but may be used just as easily by other container managers. Podman is a drop-in replacement for Docker with much better security practices.
Everything is a trade off between security/safety and convenience. You need to decide how much security on your system you want to give up for whichever level of convenience you want.
This is an interesting thread. I'm currently waiting on a DS918+ and was just doing a little research....this is kinda scary 
Is this singled out to Synology?
I don't know as it should be "scary," necessarily. I'll try to explain the issue as succinctly and clearly as possible.
Microsoft Windows has been a security nightmare up until MS-Windows 7 in large part because users always automatically had Administrator privileges. This meant everything got installed and run with complete access to all aspects of the operating system at all times. Thus it was easy for the computer to be exploited. And it was. Frequently.
In Unix and Linux the equivalent to MS-Windows' Administrator is the "root" user. Often referred-to as the "superuser."
Traditionally, users in Unix and Linux did not run as or with root privileges. This is one reason why *nix systems have traditionally been more secure than MS-Windows systems. (One Unix geek, many years ago, once cautioned "Running as root is like driving without seatbelts.") Furthermore, starting, I dunno, twenty years ago or so, the writers of system services code to run under *nix systems started writing those to run under unique user i.d.s, rather than as root, so if the service was compromised or had a weakness, the service wouldn't have free reign over the whole system, either.
The problem with the Channels DVR service installed on *nix systems (and Linux is the core of Synology's NAS and others) is they install and run it as root. Thus: If it has an exploitable weakness, that weakness could, if exploited, result in exploit code being installed, giving bad actors access to the system to take whatever they want from it, install ransomware on it, use it to launch attacks against other things on the network or the Internet, etc.
Notice the "if"s and "could"s.
So, while it's a concern, I don't know as I'd lose any sleep over it.
While I'm not comfortable with it, neither am I "worried" about it, per se, because I keep nothing sensitive on our NAS, anything else sensitive we have on our LAN is independently secured, and the NAS is prohibited from accessing the Internet for other than Channels by the firewall rules I've implemented.
It applies to any system or appliance using a version of Unix or Linux as its operating system.
1 Like
So are you theoretically saying that even on MacOS, I should create its own account for Channels as it is being ran under my uid which could be compromised if a weakness is ever found?
Really can't help you with Mac OS X. I've no experience with it, other than very briefly using an OS X-based Mac laptop for a development project many moons ago.
OS X is based on a version of Unix, but I've no idea what enhancements may have been done to make it uniquely Mac OS X.
If, when you install a service on Mac OS X, it has the ability to install and run that service under the UID under which you're logged-in at the time, that would be a significant departure from traditional Unix/Linux operating systems. I would have assumed that, upon installation, the OS would ask you to approve the elevated privileges usually necessary, under a *nix OS, for installing them.
Traditionally, what happens on a *nix system is you approve being temporarily granted elevated privileges (or explicitly assume them, using commands such as "su" or "sudo") in order to install a package, create the necessary directories, etc. If the package is designed to run with package-specific user and group identities, the package installer automatically creates the necessary IDs, makes sure everything specific to that package is assigned those IDs, and the package is started-up and run under those IDs.
I would be surprised if Mac OS X operated any differently, but, as I said: I really don't know.
1 Like
Folks, I really wouldn't get all wrapped around the axle over this issue. TTBOMK, the Channels DVR service is neither exploitable nor has ever been exploited. Does that mean it can't be or that it won't be? No. But I've seen no evidence to suggest it either is or has been.
The reason for not installing such things with superuser privileges is kind of a safety net thing.