Describe the bug
I've already opened an issue on the jellyfin-web repo, but it seems to be more on the server's fault. Here it is: jellyfin/jellyfin-web#1008
If you launch a newly created Jellyfin server and use another web client than the one provided by the new server (say a development version), you can login as 'root' without any password.
System (please complete the following information):
- OS: Docker
- Clients: Browser
- Browser: Firefox
- Jellyfin Version: 10.5.2
To Reproduce
- Launch a new instance of Jellyfin (say the Docker image)
- Reach a web client not distributed by the server (a development build)
- Add the new server to the client
You can now see a user displayed, 'root'. You just have to click on it to login without password.
Expected behavior
Showing the wizard if using it from another client than the one distributed by the server is supported, or simply showing no user.
It seems that disallowing logging in should be the expected behavior, see below.
Additional context
I'm trying to fix something in the wizard so I need to reach a fresh instance of Jellyfin with my development build of the web client.
Moreover, being able to freely login as a root user has always been a bad behavior, especially when not expected. I think it should at least be disabled, or better, showing the wizard.
I started some research and I've found something. It seems to be that not showing the wizard is done on purpose. When hitting the wizard URL on the external client (after having configured the server I want to reach and logged in as root) http://localhost:8080/index.html?start=wizard#!/wizardstart.html?start=wizard, I reach the wizard page but I am being hit with a CORS refusal. So at least, it seems the server is handling differently the startup requests than the others. Maybe forcing the wizard on the client distributed by the server should be the solution to respect what's already in place.
So it seems that, seeing the CORS refusal when trying to load the wizard from an external client, the first time setup should be done on the same domain as the server.
From a security point of view, we shouldn't be able to log in on an uninitialized server, much less as a 'root' user. I think the easiest fix should be to block non first time setup requests until the first time setup is done.
ThibaultNocchi
All 7 comments
This is kind of a chicken and egg problem, but we could circumvent some of the issues by refusing all endpoints besides the wizard until it has been completed. Someone could still just take control of the wizard though. I would much prefer a CLI tool to generate a random password during the first run and a headless mode that doesn't require the web client.
dkanada on 31 Mar 2020
👍1
You're right, I haven't thought about how useless it is to block endpoints as anybody can still run the wizard.
I like the idea of a password to setup Jellyfin. How would that work, especially the headless mode?
ThibaultNocchi on 1 Apr 2020
There are lots of ways we could do it, but the easiest would be removing the wizard completely and relying on the configuration files to be manually changed. We could also bundle a simple CLI tool like Synapse does for their server.
dkanada on 1 Apr 2020
👍1
I think a CLI tool could be better than simply relying on users editing the config files. How would we go making such a tool, would that be C# or could it be anything else?
ThibaultNocchi on 1 Apr 2020
We’d have to make sure that any change here still let’s us have the wizard in certain scenarios. I don’t want to make things too complex for new users :-)
On Windows and macOS systems, we launch the browser with the wizard right away on first launch, so you’re kind of “pushed” to set it up.
I don’t know how to reasonably solve it for our Linux/other users. A plan is to eventually be packaged for NAS “app stores”, and as a Snap (among other things). Those contexts would benefit from also just having the Wizard easily accessible.
anthonylavado on 1 Apr 2020
I figure we could still have a wizard, but just authenticate it as well and somehow supply a user with a randomly generated password. It could be a CLI tool that could also get automatically run during the Windows and macOS installers to keep those installations easy.
dkanada on 1 Apr 2020
👍1
I'm thinking, we could just disable CORS requests while the first time setup isn't done? At least nobody from outside your LAN could set it up.
For now the problem is being able to login as root while using another client, so if we extend the same CORS ruling as there already is on the wizard to requests before first time setup, I think it could fix the problem without being problematic to users.
ThibaultNocchi on 1 Apr 2020
Was this page helpful?
0 / 5 - 0 ratings
