Allow to bind to priveleged ports (i.e. 80/443)

[brianjmurrell]

Changes
Add AmbientCapabilities=CAP_NET_BIND_SERVICE to the [Service]
section of the unit file to allow the server to bind to ports 80 and 443.

This is useful on stand-alone instances of JF, where standing up a separate "reverse proxy" is simply overkill just to allow "standard port" access for a web service.

[brianjmurrell]

Anyone care to review/comment?

[crobibero]

I don't think this is something we want to allow by default.
I've been told that you can just run systemctl edit jellyfin.service where you can create overrides for everything and they survive upgrades.

[brianjmurrell]

This is a very specific and targeted capability. It's not like setting a blanket permission such as SUID-root or anything. All it does is allows JF to bind to a port <1024. The harm in that, even if JF was exploited would be minimal IMHO.

[stale]

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.

[Shadowghost]

I don't like this change. There is no reason or need justifying allowing to bind to privileged ports by default.
I disagree with your opinion that this is a very specific and targeted capability. The attack surface is way broader if you can bind to ports usually used by well known services just by modifying the Jellyfin config. There is a reason those ports are called privileged and need special permissions in the first place.
If people really want to run Jellyfin on port 80/443 they can just edit the service. Making it an explicit choice is the corret approach in my opinion.

[brianjmurrell]

The thing is, the supposed security enhancement of not allowing binding to lower ports is antiquated and pretty much entirely moot any more.

It came from a time when a computing resource was scarce and expensive and one usually used a well-known resource of some large organization. Preventing non-root from impersonating well-known services on such a system had value.

Now everyone has (multiple even) personal computing devices, that they are root on and can impersonate all they want.

(Apparently) even Windows doesn't impose this restriction any more, most likely as they have come to the same conclusion that it doesn't really matter any more.

You know, really, whatever. It really should not be this difficult to try to contribute to a project to make it easier to use.

[brianjmurrell]

I've reworked this PR to put the additional capability into a separate subpckage so that it's only active/applicable to sites that want it and get it by installing the jellyfin-server-lowports RPM.

If somebody could please review, I would appreciate it.

[crobibero]

Was the additional % accidentally added?

[brianjmurrell]

No. It's an escape. Macros get expanded, even inside comments which is typically not what is desired. The RPM linter will complain about them.

[cvium]

Why another package? Can't people just edit the systemd service with a small override?

[brianjmurrell]

Why another package? Can't people just edit the systemd service with a small override?

Because my target audience is real end users, not engineers or hobbyists, etc. The kind of end users that just want a media server that installs straightforwardly and don't want to have to scour websites, and readmes, and forums, and help boards, etc. for instructions on how to fiddle their installation to have it act "normally" (i.e. web services normally are on ports 80 and 443 -- so normal that the ports don't even need to be part of the URL -- not unusual high ports which need specifying in the URL).

My goal is the highest standards of ease-of-use.

I am happy that a lot of Jellyfin is already in that camp. Other areas less so, but if I can make any part of running it on regular/usual ports all that much easier, why not?

I might ask you the contrary, why not a package that somebody can easily install without having to know how to muck with systemd? What is the problem with a package that enables more ease-of-use?

The previous rejections on this PR were that it was opening up a security hole for people that didn't need/want the feature. I have resolved that now. It's now completely optional and targeted at people who only want the feature.

[brianjmurrell]

Any more review/comments/etc.?

[brianjmurrell]

Could we please get further review/comments on this PR? @joshuaboniface perhaps you have some thoughts?

[joshuaboniface]

I'm OK with this, makes sense to me.