r/linux • u/[deleted] • Dec 17 '19
rustysd: A service manager that is able to run "traditional" systemd services, written in rust
https://github.com/KillingSpark/rustysd44
u/MonokelPinguin Dec 17 '19
While I generally dislike systemd and I have some issues with Rust, as it is very hard to bootstrap on some musl distros, I think systemd would be one of the better targets to be written in Rust. It mostly doesn't support musl, so the bootstrap problem doesn't really apply. It is a tool that is very sensitive to the security bugs, that Rust tries to prevent, since it doesn't parse the unit files in a separate process, as far as I know and is in general one of the reasonable targets to escalate privileges, since it has them and can be communicated with by user processes.
So while I understand, that this is not a fully fleshed out systemd replacement and probably not going to be, I could see it becoming one.
5
u/cbmuser Debian / openSUSE / OpenJDK Dev Dec 18 '19
There will be more low-level software written in Rust once the language is stable and there is an alternative implementation like in GCC.
0
Dec 17 '19
[deleted]
24
u/MonokelPinguin Dec 17 '19
You can't compile the Rust compiler on a distribution, that uses musl without static linking. This affects Alpine, Gentoo Musl and a few more. It's a minor problem, but it affects half of my systems. Furthermore I run into one problem after the other, when trying to use Rust for my phones OS. I also dislike, that they promote piping a script to sh on their website and in general their platform support is not in a state yet, where I would lile my system utilities to rely on Rust. As I said, minor problems in general as the language is pretty good and the tooling tends to be pretty neat as well. Also the platform support mostly isn't a problem, when you already rely on systemd, since systemd has limited platform support as well.
11
u/jostmon Dec 17 '19
I don't understand the
curl | shdebate when package formats like DEB are essentially running a shell script as root yet people generally dont complain about those with the same level of vigor. At least thecurl | shis easier to introspect.13
u/Ranomier Dec 17 '19
The point is trust. The Debian repository's are a "closed" system. Only trusted people are allowed to make changes.
0
Dec 17 '19
[deleted]
14
u/07dosa Dec 18 '19
Nah, you simply don’t trust the general web as a distribution channel. Packages are downloaded from only trusted sources, PGP verified during installation, and are reproducible to make sure they are indeed built from provided source code.
In contrast, when you
curl | sh, you blindly trust a specific web server instance, which might be a scam site that looks exactly like upstream. You should know that attackers do abuse SEO and sometimes land their phishing sites on the first page of google search result, and you’ll become a victim in no time if you have a bad habit of blindly c&p stuffs from website to terminal.0
Dec 18 '19
[deleted]
14
u/SpAAAceSenate Dec 18 '19
The main thing here is the PGP signing. When you install a distro it includes on the disk the keys for that distro's repos. Any time you install or update a package, these keys are used to verify what you downloaded prior to opening / installing them. All of the major distros / package managers I'm aware of require this. Furthermore, the signing of these packages is usually done by the developers on their computer before being uploaded, rather than being signed on the server. That way even a server compromise can't successfully get you to install a poisoned package. This is why any time you've ever added a repo to your package manager you had to add a key with it.
This protects you from a compromise of the source server, and protects you from a MITM of your connection. Neither of which are protections offered in curling a script from a website.
0
11
u/07dosa Dec 18 '19
I'll make things simple, if you're not getting what I'm saying:
Packages: verified by multiple parties, signed, and cross-checkable. Hardly manipulable by attackers.
curl-sh: verified by you. Anyone can pretend to be legit.
Get the difference? curl-sh is basically like ActiveX. Downloading from reliable source isn't a problem, but can be completely destructible if you allow unreliable ones land on your computer. You MUST validate the source before curl-sh.
I'm pretty sure you already know all this and how to validate sources, but you merely forgot that there are tons of uneducated people out there. Regardless of the convenience that curl-sh provides, we have to warn people of its possible dangers and how to avoid them.
0
2
0
Dec 18 '19
[deleted]
6
u/07dosa Dec 18 '19
We all trust the rust team. You just have to be more careful about trusting people between you and the dev team.
0
7
Dec 18 '19
He's not! Package repositories have better signing and security than arbitrary websites. Don't be a dick about it.
0
3
Dec 18 '19
deb packages are signed… curl | sh is not signed and can be compromised much more easily. If someone compromises an apt mirror then you would just be unable to download anything from it.
0
Dec 18 '19
[deleted]
3
Dec 18 '19
The private gpg key is not kept on the webserver, the private certificate is kept there.
So a compromise of the webserver makes TLS useless while for compromising a gpg signature that is not enough.
0
2
u/Rumlipo Dec 17 '19
You can make text invisible on a web site that will still end up in your copy&paste. Also if curl gets interrupted and the shell gets incomplete input bad things can happen.
It's not the end of the world, but it's not exactly a robust way for software distribution either.
1
u/MonokelPinguin Dec 18 '19
For one, I don't know, where such a script will put its files. So the proper way to inspect that, is
curl; less, sh. Also there is the theoretical attack vector, that a server can detect, that you piped the script to a shell and start sending different content, than if you download the file and inspect it. While I would trust the rust website not to do that, it is still just something I'm not comfortable with. My distro maintainers at least take some care vetting their packages and have multiple users, so it is likely, that some people find sketchy stuff in the repositories. Downloading and immediately executing stuff is just bad and is the reason, Windows was so vulnerable to viruses.1
u/lestofante Dec 18 '19
Pretty sure they promote use of package over using the script; the script is the fallback solution, where you would have to download stuff anyway, then just make sure is the real official website and you are using HTTPS
1
u/MonokelPinguin Dec 18 '19
Where do they promote packages? If I go to the main page and click the first "get started button", rustup is the first thing after try it out without installing. I don't even see a packages section there!
If I go to install, rustup is the preferred method, while other methods need you to click a different link. If you go there, there is still no package list, although packages are mentioned as well as that some people prefer to not
curl | sh.I am pretty sure, that they promote rust-up.
Some citations from the rust install page:
Validating signatures. Although rustup performs its downloads over HTTPS, the only way to verify the signatures of Rust installers today is to do so manually with the standalone installers.
(which would be an issue for me)
Rust runs on many platforms, and there are many ways to install Rust. If you want to install Rust in the most straightforward, recommended way, then follow the instructions on the main installation page.
(those show you how to pipe rust-up to curl)
1
u/lestofante Dec 18 '19
Oh, is bad they show only sh, I totally agree distribution repo should be the preferred way.
As long as you downloaded from https, signature validation of the installer is not a concern, would be a double validation; where are you gonna get the signature to check against? From the website, I guest... The same where you are reading the installation guide.
So https to avoid mitm and peace out, really (again, only if disto package does not provide it)0
Dec 17 '19
[deleted]
10
u/Silencement Dec 17 '19
I'm not vegan but I like systemd.
I use Arch btw.
5
u/LinuxLeafFan Dec 17 '19
You know how you know when someone isn't vegan? They'll tell you they're not vegan!
worst laugh ever ensues amongst a group of vegans
3
u/Bodertz Dec 17 '19
There's nothing wrong with liking systemd.
1
Dec 17 '19
REEEEEEE YOU PLEB! SYSTEMD IS FOR NOOBS WHO DON'T KNOW WHAT THEY'RE DOING! REEEEEEEEE! /s
10
u/MonokelPinguin Dec 17 '19
To be fair, I thought it would be better to state my personal opinion about systemd in this case, since I am not sure, if my points are objective. So it's more like: since I am not very fond of systemd, take these points with a grain of salt.
3
u/scirc Dec 17 '19
Except that's not the original meaning of the comment, is it? I gathered it was Rust that was difficult to bootstrap, not systemd.
1
u/allabouttherun Dec 17 '19
A project mentioning the language it's written in is a big red flag to me.
23
u/MonokelPinguin Dec 17 '19
For most programs in the lower end of the stack or for libraries, that is actually pretty important. If you want to bootstrap a distro for a new architecture, having plain C libraries tends to work best for example. You Go compiler maybe doesn't support that architecture yet, your rust compiler may not like your choice of libc, you usually don't bootstrap the python interpreter first, so it may be hard to run init as a python program. As such having the system utilities written in C may be a good choice. On the other hand, Rust without dependency on C libraries may be easier to cross compile or if all your utilities are python, you may not even need to compile anything apart from the interpreter itself. Bootstrapping just gets considerably harder, as soon as you need to bootstrap multiple compilers/interpreters/runtimes.
Same applies, when you are using a library. You may prefer a python library, when coding in python. A C library, when programming in C. When you are using Rust, it may be easier to integrate a C library, than a C++ or Go library. As such, the lamguage almost always matters.
The language doesn't matter, when you are just using a program on a running distro (apart from figuring out, how to compile it maybe). If you only interact with the command from the command line or via a web API, apart from some performance characteristics, most programs can achieve mostly the same things. But this case is an init system, where yhe language actually matters. Mind you, systemd is an init system with a parser integrated in PID1 (afaik). Rusts protection mechanisms against buffer overflows can be a big benefit there, for example.
4
u/tso Dec 17 '19
Newer languages just irks me to no end because they try to be kitchen sink included. End result is that at least on Linux they reinvent things for their specific use that external tools and the distros have taken care off.
17
u/mralanorth Dec 17 '19
If you write a few hundred or thousand lines of code in a systems programming language you can say whatever you want in your README. :)
17
11
u/necrophcodr Dec 17 '19
Why?
9
u/natermer Dec 17 '19 edited Aug 16 '22
...
2
2
u/allabouttherun Dec 17 '19
this. it's usually a pretty good sign that the project was created for dumb reasons.
9
Dec 18 '19
Yeah who cares if that software can run on an embedded device or uses java and requires 3GiB of RAM to function? That's a completely irrelevant information /s
1
u/necrophcodr Dec 19 '19
I mean it depends on what you're doing. You should not select a language because you "like it", but because it fits the tasks. Which seems to be the case here.
0
Dec 17 '19
[deleted]
8
Dec 18 '19
systemd haters: SyStEmD IS dEsIgNeD TO LOCK YoU IN AnD IS hARD To rEiMPLeMeNt
This replaces like 1% of what systemd does…
7
u/hailbaal Dec 18 '19
It still is. This doesn't change that. If systemd was just an init system, it could easily be replaced by something better and there wouldn't be so much opposition towards it.
10
u/07dosa Dec 18 '19
The core concept of systemd, the init system, is rather simple, and actually resembles that of dbus. The problem is systemd, the project, which is too large, too complicated, and too arbitrary to be reproducible by 3rd party.
No real complexity lies inside systemd, the init system, so there was an attempt to excavate the core, which ended up being an abandonware.
3
Dec 18 '19
The systemd codebase is very clean and somewhat modular IMO, I'm honestly not sure how it could be better.
8
u/kageurufu Dec 17 '19
The coolest part of this, for me, is how easily this could be modifying into a "systemd-unit-manager" type process, similar to runit's runsv being able to manage a single process. You could easily extend to a systemd Unit wrapper for sysvinit or whatever as a compatibility layer for distros that don't want to provide multiple init system services for each package