Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
I don't think downplaying them is the way to go though, Some of these issues have been in existence since 2019.
Like I mentioned though, it does seem like its starting to be worked on, a few of them are in progress the one I really don't like is #13991 which is a combination of:
For example I just made a user with no access period to any collection, just a login access and took the auth token for the user. I was able to grab every user on the servers ID including hidden and administrative users as well as users who don't use jellyfin's auth system, then couple that to see what the users login method was, when their last access was, what folders they were allowed to use[note these are represented as id's the client can't actually parse them so you need to traverse the api for it], how many max sessions they could have, etc. without actually having access or logging in as that user or even being an administrator. If you snag an admins userid it even gives you internal server data such as logging paths that the server uses on the dashboard, the transcode path, the metadata path, what networking settings the server is using such as trusted ip nets the port jellyfin is using by default your certificate file and password if configured[although password may be ommited/the field left blank i didn't test internal certs]. From there you can even recurse through the folder UUID's provided via "enabledfolders" and the other folder restrictions on the users endpoint and get the name of the folders which could leak personal information about the library or the user because the 403 request it returns leaks the name of the library as part of the error message. "username is not allowed to access Library name"
Thankfully it's finally being worked on but, I do think it's worth stating the timeframe on them and that those issues do still exist.
Just like I think it's worth stating that media endpoints are still fully unauthenticated as well, so as long as you can guess the full file path, you can md5 it and get unauthenticated media paths, but that's in progress as well, its just super slow because that breaks third party clients.
I am not downplaying them. And yes they should get fixed. But this attack needs access to an account on your server.
Yes, also should be fixed, probably by some sort of salt and authentication, but can be easily prevented by adding a random character in the base/root path to the media. Especially with docker or similar, thats an 1 min fix.
And even if not? What then? Why would someone want to attack that?
Those are not good, no. But no deal breakers and actually more blown up then downplayed imho.