4 ms·
I think this kind exposure is inevitable with something as big as systemd. If you look at the old scripts-and-daemons hairball that systemd replaces, it has a l
by NelsonMinar 7y ago
I think this kind exposure is inevitable with something as big as systemd. If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. (Albeit with 20 years of wart removal as well.)
What worries me is that systemd is not engineered and managed as a project with this kind of risk. Instead it feels like a lot of cowboy coding.
- qxnqd 7y agoSystemD should not be as big as it is.
- zzzcpan 7y ago> If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. Not even close. Scripts were always memory safe and limitations of shell didn't allow to go crazy with things and introduce security issues left and right.
- dfox 7y agoWhether shell is memory-safe is completely irrelevant as the language has more significant safety issues with regards to quoting, eval and such. And second reason why it is irrelevant is that the traditional bunch-of-shell-scripts init system does not process any kind of untrusted input.
- zzzcpan 7y agoIt does deal with some untrusted input, often not directly in shell though, but through other tools.
- bonzini 7y agoInstead you had quoting bugs where the shell scripts ended up rm -rf /'ing your machine.