Horrible headline hides even more disturbing story.
-
thenextweb.com 'rm -rf -no-preserve-root /' deleted the laptop's EFI as well. Systemd devs say this shouldn't be possible.
How bad is thenextweb.com on reporting? Haven't heard of them in a long time now before this popped up.
-
Never heard of them. Sounds like they just discovered computers.
-
"To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that."
https://github.com/systemd/systemd/issues/2402#issuecomment-177907110
-
@Breffni-Potter said:
"To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that."
https://github.com/systemd/systemd/issues/2402#issuecomment-177907110
Why, why, why, would you ever even have the option to make the entire EFI writable instead of just what you need?
Going to add this to my list of things that systemd does wrong.
-
@travisdh1 said:
@Breffni-Potter said:
"To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that."
https://github.com/systemd/systemd/issues/2402#issuecomment-177907110
Why, why, why, would you ever even have the option to make the entire EFI writable instead of just what you need?
Going to add this to my list of things that systemd does wrong.
It sucks because there is no way back, unless you use the fork of Debian or something else that no business would use. Or unless RH and Debian decide they aren't going to use it any more.
-
@travisdh1 said:
@Breffni-Potter said:
"To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that."
https://github.com/systemd/systemd/issues/2402#issuecomment-177907110
Why, why, why, would you ever even have the option to make the entire EFI writable instead of just what you need?
Going to add this to my list of things that systemd does wrong.
I haven't really seen anything from Lennart that didn't sound cocky and douchey.
One person had what sounded like a good idea. Just mark the files immutable and if the scenario comes up where they need to change, then change them temporarily. This was the response he was given:
I don't think anyone's going to implement (and merge) the overkill of file attributes to the efivarfs pseudo-file system.
How is that any more overkill than mounting and unmounting a file system?
-
I also don't get the reason for binary logs. Here's a list he put together, but I have a hard time believing most of these can't be fixed with MAC such as SELinux. And can't the same arguments be made for everything else that's file based and not a binary object? If so, why not just change everything to binary objects?
If you need speed with parsing logs, why aren't you using ELK or Splunk?
https://www.quora.com/Why-are-systemds-logs-stored-as-binaries
-
Don't get me wrong, some things about systemd are kind of nice. Like separation of services (especially within chroots), being able to restart services, easy syntax (if that can be a plus), utilization of cgroups, and parallel processes I guess are nice (but does booting faster make that much of a difference?)
It would be nice if you were able to decide which you wanted to use at install.
-
@johnhooks said:
I also don't get the reason for binary logs. Here's a list he put together, but I have a hard time believing most of these can't be fixed with MAC such as SELinux. And can't the same arguments be made for everything else that's file based and not a binary object? If so, why not just change everything to binary objects?
If you need speed with parsing logs, why aren't you using ELK or Splunk?
https://www.quora.com/Why-are-systemds-logs-stored-as-binaries
I actually like binary logging, but the security bits I question. But for large systems, size and speed on disk and at the time compression are huge. The rotate and compress mechanism from the syslog era is pretty sucky.
-
@scottalanmiller said:
@johnhooks said:
I also don't get the reason for binary logs. Here's a list he put together, but I have a hard time believing most of these can't be fixed with MAC such as SELinux. And can't the same arguments be made for everything else that's file based and not a binary object? If so, why not just change everything to binary objects?
If you need speed with parsing logs, why aren't you using ELK or Splunk?
https://www.quora.com/Why-are-systemds-logs-stored-as-binaries
I actually like binary logging, but the security bits I question. But for large systems, size and speed on disk and at the time compression are huge. The rotate and compress mechanism from the syslog era is pretty sucky.
I haven't dealt with anything large at all, so I guess I haven't seen that. I didn't realize it was that bad when you had much larger systems.
-
@johnhooks said:
I haven't dealt with anything large at all, so I guess I haven't seen that. I didn't realize it was that bad when you had much larger systems.
If you are on SSD everywhere, might not be so bad. But at the bank, for example, going through logs was painful. Took up a ton of memory while loaded, certain tools could not be used to open the files, long load times, very long scroll times, slow searching, etc. When you have 10GB of text in a single file, things slow down.
