2 ms·

>The reason I called out the memory unsafety of systemd is to underscore how irresponsible it is for it to be parsing messages from untrusted sources as root in

by srslack 10y ago

>The reason I called out the memory unsafety of systemd is to underscore how irresponsible it is for it to be parsing messages from untrusted sources as root in PID 1. systemd-notify is "parsing", in your scenario by passing the message in the simple key-value format that systemd expects, which is the only "parsing" that PID1 really does, along the notification socket. For everything else, there's generators. This wasn't a "parsing" bug in PID1, it was a logic bug. And further, what would be a 'trusted source'? Something that would've done the same thing, passed a data structure that PID1 has to receive and understand? Your ranting is nonsensical, considering that it's doing pretty much exactly what you wanted.

papaf 10y ago
simple key-value format that systemd expects, which is the only "parsing" that PID1 really does The important word in the grandparent comment is "untrusted". HTTP and SMTP are simple key-value formats that most people would not consider parsing in a root process in a language like C. You make a good point about there being no safer alternatives though given the architecture of systemd. What does that suggest about the architecture of systemd?
- srslack 10y ago
  >"untrusted" So you're going to "trust" i.e. deputize some theoretical daemon that will still have to pass the simple data structures to systemd, which won't actually fix, or fix any future incarnations of, the bug that we're discussing. >What does that suggest about the architecture of systemd? It suggests that it is, at worst, the same as the status quo on Solaris and macOS. In reality, the community is filled with people waving their hands and doomsaying against "complexity", ignoring the fact that their suggested actions don't really solve anything. They seem to be a cargo cult of modularization, if you catch my drift. Along with all of the comments in the thread suggesting languages that can't fork, and languages that can easily lose track of daemons even when the daemon doesn't double fork, we can see that not every suggestion that sounds reasonable is actually reasonable, or better. Additionally, there's probably some lesson about `PR_SET_CHILD_SUBREAPER` and what happens when the subreaper they so desperately want to exist crashes. If systemd were running as PID2, and crashed, children would simply be inherited by PID1, and now we need to communicate everything to the service manager. You can't set subreaper again, after it crashed. So really, what are we arguing about here?

by srslack 10y ago

papaf 10y ago

simple key-value format that systemd expects, which is the only "parsing" that PID1 really does The important word in the grandparent comment is "untrusted". HTTP and SMTP are simple key-value formats that most people would not consider parsing in a root process in a language like C. You make a good point about there being no safer alternatives though given the architecture of systemd. What does that suggest about the architecture of systemd?

srslack 10y ago
>"untrusted" So you're going to "trust" i.e. deputize some theoretical daemon that will still have to pass the simple data structures to systemd, which won't actually fix, or fix any future incarnations of, the bug that we're discussing. >What does that suggest about the architecture of systemd? It suggests that it is, at worst, the same as the status quo on Solaris and macOS. In reality, the community is filled with people waving their hands and doomsaying against "complexity", ignoring the fact that their suggested actions don't really solve anything. They seem to be a cargo cult of modularization, if you catch my drift. Along with all of the comments in the thread suggesting languages that can't fork, and languages that can easily lose track of daemons even when the daemon doesn't double fork, we can see that not every suggestion that sounds reasonable is actually reasonable, or better. Additionally, there's probably some lesson about `PR_SET_CHILD_SUBREAPER` and what happens when the subreaper they so desperately want to exist crashes. If systemd were running as PID2, and crashed, children would simply be inherited by PID1, and now we need to communicate everything to the service manager. You can't set subreaper again, after it crashed. So really, what are we arguing about here?