Distributors ponder a systemd change

Posted Jun 8, 2016 4:34 UTC (Wed) by rahvin (guest, #16953)
In reply to: Distributors ponder a systemd change by Nahor
Parent article: Distributors ponder a systemd change

You're simplifying the problem. A zombie user process is a threat precisely because no one is actually in control of it making it available for anyone to potentially exploit with the user that started it no longer monitoring it. You don't have to distrust your users for that to be a security issue. I can think of hundreds of ways that could be bad even with a completely trusted user because everyone makes mistakes, zero day exploits exist, and zombie processes are an avenue for all kinds of mischief.

What if you had an orphaned ssl process when the heartbleed vulnerability was disclosed? Even if you patch the binary if you don't shutdown the zombies you just exposed your key to the world. IMO this is a good change to enable default security but I also totally agree that this should have been talked about very publicly that they were going to turn it on with X release. By not doing this they sabotaged their own effort because all the distributions will just disable it and boom it will never get implemented as default. And these programs like tmux and screen whose primary purpose is to daemonize a process (and have been around for more than 30 years) should have not only been warned but the systemd developers should have found a good way to retain that functionality that wouldn't require a dependency (in an upstream that's agnostic to the OS) to fix, even if that is a default exception for those specific binaries.

tldr It's a good change but it was handled terribly.

Distributors ponder a systemd change

Posted Jun 8, 2016 4:41 UTC (Wed) by drag (guest, #31333) [Link] (4 responses)

A zombie process is one that is killed and is waiting for the parent to reap it's return code.

There is no threat from them. They are not running anymore. They may be using up some memory in a process table or something, but that is about it. All it really means is that if you end up with a bunch of zombie processes you have a bug in the kernel or init or something.

Distributors ponder a systemd change

Posted Jun 8, 2016 8:57 UTC (Wed) by sbakker (subscriber, #58443) [Link] (3 responses)

I suspect rahvin meant "orphaned" rather than "zombie". Nevertheless, the term "zombie" is confusing, implying that the entity is somehow still active. It isn't. In fact:

“This process is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late process. It's a stiff. Bereft of life, it rests in peace. If its parent had reaped its exit status, it wouldn't be occupying a process slot, but pushing up the daisies instead. It's rung down the curtain and joined the choir invisible. This is an ex-process.”

A better name for zombie processes would be "corpse" or "carcass", but that just looks wrong in "top" listings. "Dead parrot" has a nice ring to it though.. :-)

Tasks: 304 total,   1 running, 303 sleeping,   0 stopped,   0 dead_parrot

Distributors ponder a systemd change

Posted Jun 8, 2016 15:44 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

Yes, I figured we might as well be consistent in what we are talking about here. Zombie is a very commonly used term.

A 'orphaned' process is essentially a daemon.

The problems we are running into now is that in Unix-ville every application was tied to a TTY. The 'getty' process was the 'session manager'. However it's complete shit to work in a modern environment by 'backgrounding processes'. So using daemons for setting up user environments and such things are very common. So is using terminal multiplexers like tmux or screen.

These are really just bandages to a bigger issue. All these things are just work arounds to the 'tty' limitations. As a result it's a big mess. You can control when you start up all these processes, but they are no longer tied to anything. You have to have some process to come back in when you log out to clean them up.

With systemd we now have the ability to have a true user session that is no longer tied to a particular tty. Systemd can 'daemonize' processes without actually going through the traditional deamonizing processes. It makes sense that when the user session dies so does their programs. It's just the way things should of always worked.

Distributors ponder a systemd change

Posted Jun 8, 2016 21:02 UTC (Wed) by rahvin (guest, #16953) [Link] (1 responses)

I did mean orphaned. I had one of those moments where I couldn't think of the right word so I used a different one.

I completely agree this is a needed change. The problem is it breaks 30 years of experience, and those types of breaks need lots and lots of warning or people will put workarounds in place that negate the change. Every distribution disabled it, IMO that's a sign they handled the messaging wrong.

Distributors ponder a systemd change

Posted Jun 8, 2016 23:35 UTC (Wed) by johannbg (guest, #65743) [Link]

"IMO that's a sign they handled the messaging wrong."

If by "they" you mean downstream distribution package maintainers of systemd you might be right depending on which community you reside in.

If by "they" you mean the upstream systemd community, it follow standard announcement procedure like most project do and that even got picked up and announce here on lwn [1].

Unlike many upstream project there is also always last call [2] open for couple of days before each upcoming release ( encase someone might have missed something or wants to discuss some change before release ) and for some facts ( since some people might find those relevant ) the change was committed in early april and it was Zbyszek that was pushing for this change not Lennart ( but apparently the pattern is blame Lennart or Gnome for all the world problems ).

1. https://lwn.net/Articles/688640/
2. https://lists.freedesktop.org/archives/systemd-devel/2016...

Distributors ponder a systemd change

Posted Jun 8, 2016 12:03 UTC (Wed) by itvirta (guest, #49997) [Link]

> What if you had an orphaned ssl process when the heartbleed vulnerability was disclosed?
> Even if you patch the binary if you don't shutdown the [running processes] you just exposed your key to the world.

That's a problem with all binary / library upgrades (libc and static binaries too). You need a way to find if a process is still using the old binary, and for long-running services
that needs to be done during the upgrade, not during some arbitrary point in the future, like someone's logout.

Distributors ponder a systemd change

Posted Jun 8, 2016 16:07 UTC (Wed) by Nahor (subscriber, #51583) [Link]

You misunderstand my question. My question is not about why it's dangerous to keep an orphaned process running but why it's *more* dangerous than a non-orphaned process. Why is it risky to keep a process running while logged out but it would be acceptable to keep that same process running with a user logged in 24/7?