… well. You’re right: passwords are a way to restrict access. That’s why one shouldn’t share passwords if there’s no real need. The guest network feature on consumer grade wifi routers is usually quite easy to set up - don’t be afraid. If there’s a better way to do things why insisting on what one’s used to from the past? When the babysitter’s on the guest network no nasties happen, well at least not in your then more private home network.
I’m not saying that Roon should not have rights and user management. But I believe that as long as there’s none you still can operate Roon quite safely when taking some other precautions - most of which you should take even if you don’t run Roon at all.
Pretty certain I have not heard so much Nanny State rubbish for a long time, who cares if someone can see what music you listen to? that assumes of course that they have even heard of Roon and know there is an app to download - pretty certain they won’t unless you tell them. What could they do delete it all… well if you don’t have a back up then thats no worse than your hard drive failing is it…
I think an absolute first step would be to be able to disable (ON THE ROON SERVER, NOT ON THE ROON CLIENTS - ANYONE CAN ACCESS THE ROON CLIENT) the ability to delete tracks and albums.
The rest, I can do myself: the WiFi security and the local PC files and NAS files security and access control to all my home devices.
But I have a bunch of Roon clients on a bunch of devices accessible by family members - and this is why I need the Roon client to not be able to delete tracks and albums.
It took decades to collect the music, and it is important to keep it.
If you use NAS storage for your Roon music library you could give the Roon server read-only access. Then it will not be able to delete files. But if you use internal storage that won’t work.
This is fairly straight forward. Make a user on the NAS (e.g., “Roon”) and give it a nice long random password. Give this user read-only access to the music share(s) on the NAS. Do not give it access to anything else on the NAS. (Optionally create a “Roon Backups” share and give the Roon user read-write access to the backups share if you want to set up automatic backups from your Roon Core to the NAS.) Then when adding the NAS to your music library, use the “Roon” user that you created, not your normal user.
Because I looked at the install script they use on Linux. It fetches from an S3 bucket and doesn’t do any verification of the tarball before extracting it.
This was discussed months ago from me and other users. There are not a single reasons why fhe Roon clients should not protected by a simple password or authorized by the server.
All reasons for not to do it (give access to trusted users on your network, etc.) are pointless.
I really still don’t understand why the security was not implemented from the 0.1 version.
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
32
There are endless numbers of software products that fail in this regard. Developers who are not “security first” almost never get it right – and developers who are almost never produce a product.
2 Likes
James_I
(The truth is out there but not necessarily here)
33
At least rudimentary security should be a high priority, along with the ability to create read only profiles.
I can see an option where you can delete from the Roon library and leave the physical file where it is , then to permit a reimport function
Deleting from Tidal for example is OK as it’s easy to repair
I don’t even know if a Roon deleted file makes it to the Recycle Bin, I think not from the very odd one I have deleted that way. I think File Explorer is a bit safer all round
Mike
This won’t work when the core is on the NAS. Will it? Is Roon core run as root on a NAS? It seems to have access to everything then. Is it possible to do what you described on a NAS running Roon core?
P.S. Confirmed. Roon is running as root on my Synology NAS. Is there any way to restrict its rights to delete files in the music library which is on the same NAS?
Removing write perms comes with the caveat that you couldn’t dump new music from the desktop and have Roon handle it from there (something the removal of which I’d imagine could be problematic for adding music to ROCK, and something I’ve never gotten to work over Docker).
The unsigned updates thing @cwichura brought up is super, super dangerous though, no matter how you’re running things, and should be a top priority for the dev team, especially given how easy it is to update everything (that ease of update is a fantastic feature, don’t get me wrong). I’d assume only a minority of users read the release notes before hitting “go”, so who knows how many devices would get infected in that type of scenario.
) time …