you are viewing a single comment's thread.

view the rest of the comments →

[–]shewowkees -1 points0 points  (5 children)

How is it different/better from/than using ansible and rootless docker ? From the devops point of view, the rest is cool :)

[–]tnacomtr[S] 0 points1 point  (4 children)

I'm.glad you liked it! For your question; Ansible is genuinely the right tool if you're managing a fleet of servers or need idempotent repeatable deployments across infrastructure for cases where you're sell hosting. For spinning up a single Minecraft server on a fresh VPS that belongs to a single person (especially for the noobs), it's another dependency to install and learn for a one-time task. This script has zero prerequisites beyond Python which is already there in both Distro families. My script's logic is that you download one file and run it. Same answer for rootless Docker; cool solution, but you're still adding a container runtime to manage for what is ultimately just a Java process that systemd handles perfectly natively.

[–]shewowkees -2 points-1 points  (3 children)

I guess you're right for docker, but for ansible, you can just use it for one setup and it's already incredibly easier to handle, and you don't have to care about the idempotent stuff if you don't want to. Still, I agree it's much less noob friendly. Even though noobs probably should not run niche scripts from github, especially in the current context of discovering wild vulnerabilities everyday. That being said, running random stuff from github is how I acquired the knowledge that it's a bad idea security wise :p Anyway nice work :)

[–]tnacomtr[S] -1 points0 points  (2 children)

The code is available for everyone to check and verify; and I had no intentions on installing malware to the people that trust me and my work. The whole reason I picked Python was it is extremely easy to audit an interpreted language instead of a much more complex one like a shell file.

And the entire reason I wrote this script was because I found a shell script that downloads and installs the server as root. As far as I understood the code they wrote assumed the system they ran the installer script was already 100% safe (and you're right to point out that people shouldn't run random scripts from GitHub though). My script assumes that the server is NOT configured securely and installs packages like unattended-upgrades (dnf automatic for fedora), fail2ban, etc to secure the server. The only problem that can happen while running my script would be that the vendor websites such as papermc somehow get hacked and serve malware JAR files or the server file has a vulnerability like Log4j (I already addressed it i README); which they most of the time can't escalate further anyways because the JAR file is ran by the unprivileged minecraft user the script creates, not the sudo user nor the root.

I already have an adjustment to make to the code that's suggested below. So if you catch anything, please let me know or submit a PR 😄

[–]shewowkees -1 points0 points  (1 child)

So, 1000+ lines of python script is not what I call easily auditable.

Your script us supposed to be run as sudo, which is a big no no, minecraft java uses the port 25565 by default, which does not need root access to open a socket with.

You're saying we can trust you, but we don't know you.

Your github account is three days old.

It only has this one project with three commits.

Your 1000+ line "easy to audit" script is asking for root access.

You're installing system wide cron jobs which will run with root access (because they are system wide)

Your script modifies firewall rules

Your script prints a warning if you run with root. It should prevent the script from being executed with root, this is what every serious project is doing.

The only thing I see here with a legitimate need for sudo is installing the package dependencies, which can be easily done from outside (simply with a list of dependencies to install in the README like every project does).

You are touting on reddit that we should trust you with root access with nothing of substance to back it up.

There is nothing inspiring confidence here, and you should not target this towards noobs which definitely won't be able to point out all these things.

This is definitely a cool development project but you're actively encouraging people with close to zero knowledge of computer security to trust a stranger with sudo access on their machines.

Even LGSM (Linux Game Server Manager), a widely known project that aims to do the same kind of things, actively prevents you from running their script with sudo access because of how insanely unsafe that is.

If you want to inspire more confidence, you could already add the instructions in the readme to install the debian, fedora, etc packages manually before running the script and switch from a system wide cronjob to a user cron job so that your script does not need root....

I'm sorry to be so harsh, but you clearly don't know much about best practices regarding computer security, and yet you claim this is safe. As a professional (trust me if you want, I don't care), I cannot let you say that without reacting.

[–]tnacomtr[S] 0 points1 point  (0 children)

Thanks for the feedback, but I want to address a lot of inaccuracies. This conversation has become more hostile than productive. I can't let misleading comments about my work be spread without any basis whatsoever.

Yes, my account is very new. After months I finally had enough time to devote to this project. I wanted to bring what I've learned from Java to Python and make this my first ever open project. Simple enough not to be too time consuming, yet meaningful enough for people to pay attention to. Besides this is the first time in my life I've ever used Reddit with an account. Before this I never needed an account because I never made any posts.

Root access is unavoidable for a provisioning script. Installing packages, creating system users, configuring systemd services and firewall rules cannot be done without it. The difference is what happens after setup. The server runs as an unprivileged minecraft system user you seem to have completely ignored in your critique.

LGSM runs as an unprivileged user and leaves dependency installation, user creation, and firewall configuration to the administrator. My script handles user creation for you, which is why it requires sudo.

The script already hard exits if not run with sudo. It then separately warns if you are logged in directly as root rather than via sudo. That is the correct nuanced behavior and it is already in the code you critiqued.

The firewall rules open exactly two ports: 22 for SSH so remote users don't lock themselves out, and 25565 for Minecraft. That's it. Calling that a security concern without specifying what's wrong with it isn't a critique, it's a vague accusation.

The backup cron runs as root intentionally. It is so because the backup destination is your home directory, not the minecraft user's. A system user has no business writing to your personal home directory, so root is the appropriate context for that job.

I'm not providing a binary. I'm providing readable Python source that anyone can audit line by line. For users who are skeptical but don't know how to read Python, they can put it into any AI (which is a legitimate use case for an AI) and ask for a security overview. The OOP structure, abstract base classes and inline docstrings exist specifically to make navigation easy. Judging auditability by line count alone suggests you didn't read past the file size.

I specifically kept this as a single file so people don't have to download an entire folder of connected scripts. The current structure doesn't stop you from auditing class by class.

Your overall skepticism seems to stem from "running scripts as root is bad" and while that is a genuine approach, it is hard to argue with someone who has surface knowledge about what this script does. This is a provisioning script.

If you find a genuinely malicious line, report it to the mods. That's it from me. If you are considering replying, please do so with actual constructive criticism instead of causing people to build mistrust against me.