I saw that they are working on big refactoring to use EFCore instead of doing direct SQL queries. I actually was surprised when they were saying that the migration will take days for some, and you shouldn’t interrupt it.

That you should not interrupt a database migration is really standard procedure. If it takes days is unfortunate, but what should the devs do? Create a migration process with weeks and months of testing that can recover after a interruption, for those 3 ppl that run on slow hardware?

Pls do not get me wrong, that the database and everything related to it is slow and basically legacy code is not good, but exactly that is beeing worked on right now, instead of continuously pumping out new features. Complaining about the exact thing that is currently in the works feels very disingenuous.

I know that the project is done by volunteers but I was just wondering whatever I should invest more time on trying to resolve the issues. Maybe my server specs are just not ideal for Jellyfin.

Why do you think they do not?

If you would look up what they are actually doing, you woulf realize that a lot of work is done to improve the underlying quality of code to make it easier to do major changes to core functionality. Quick and dirty fixes by the previously project, emby, has led to a very shitty code base that makes changes hard.

If you are using arch and do not subscribe to the rss feed, then it is on you. As described here: https://wiki.archlinux.org/title/System_maintenance#Upgrading_the_system

deleted by creator

No. The point is the performance. You cannot compare the number of cores or frequency or else across architectures. That is pointless. That is not what i have said at all.

Can you specify which CPUs you are talking about? Also we are not talking about cores. “Halving cores” means basically nothing when you compare across different architectures.

That is actually somewhat usual, isn’t it? Just compared previous gens high end with entry to mid on nvidia like 1080 vs 3060 and 2080 vs 4060. They paint the same picture.

We are far away from the times where every single generation, marks a significant performance increase. For CPU or GPU performance.

cve-2021-3156 heap overflow in sudo. roughly 10 years long in sudo. Allowed privilege escalation. It was huge.

There are many ways to harden against it, but “just disable root auth” is not really it, since it in itself does not add much.

No you can alias that command and hijack the password promt via bashrc and then you have the root password as soon as the user enters it.

With aliases in the bashrc you can hijack any command and execute instead of the command any arbitrary commands. So the command can be extracted, as already stated above, this is not a weakness of sudo but a general one.

And how would you not be able to hijack the password when you have control over the user session?

And what do you suggest to use otherwise to maintain a server? I am not aware of a solution that would help here? As an attacker you could easily alias any command or even start a modified shell that logs ever keystroke and simulates the default bash/zsh or whatever.

The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.

So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.

So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo

The attacker that is currently with user privileges on the server?

Most comments here suggest 3 things

1. least privilege: Which is ok, but on a Server any modification you do requires root anyway, there is usually very little benefit
2. Additional protection through required sudo password: This is for example easily circumvented by modifying the bashrc or similar with an sudo alias to get the password
3. Multiuser & audittrails: yes this is a valid point, on a system that is modified or administered by multiple ppl there are various reasons lime access logging and UAC for that

An actual person from the pen testing world: https://youtu.be/fKuqYQdqRIs

The sudo password can be easily extracted by modifying the bashrc.

Nope, not really. The only reason ppl recommend it is, because “you have then to guess the username too”. Which is just not relevant if you use strong authentication method like keys or only strong passwords.

deleted by creator

Do you want to prevent brute forcing or do you want to prevent the attack getting in?

If you want to prevent brute forcing then software like fail2ban helps a little, but this is only a IP based block, so with IPv6 this is not really helpfull against a real attack, since rotating IP addresses is trivial. But still can slow down the attacker. Also limiting the amount of sessions and auth tries does significantly slow down the attacker.

If you just want to not worry about it set strong passwords, and when it is a multi user system where other ppl might access it, configure Public Key Auth so you can be sure the other users have strong passwords (or keys in this case) to authenticate.

With strong passwords or keys it is basically impossible to brute force your way in with ssh.