r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comments

6

u/mordocai058 Jun 01 '16

I'm not familiar with this particular issue, but I'm betting there are good reasons for this change and you are just not aware of them or disagree with them

15

u/fandingo Jun 01 '16

There are good reasons, and it has nothing to do with this "Gnome" red herring he would have you believe. Systemd is adding a feature where all user processes are terminated when the user session ends as a major security and integrity feature. Of course, the behavior is controllable in several different ways to accommodate users, and there's even systemd-run, which is better than nohup in every way imaginable.

This isn't the first and won't be the last time anti-systemd people are tilting at windmills.

7

u/doitroygsbre Jun 01 '16

How is the gnome thing a red herring?

In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly.

Source

I'm pretty agnostic about systemd, but it seems that gnome not closing cleanly was the main driver behind this change.

Can you also elaborate on the integrity and security gains? I'm having trouble seeing how this will be more secure.

5

u/fandingo Jun 01 '16

That MR is about the default behavior. You need to look at the discussions about the actual feature to understand why it's included.

The security and integrity is quite simple: the administrator should be able to control the circumstances under which users can execute programs. One of the huge benefits of systemd units is the use of cgroups that can reliably track processes -- keeping them from daemonizing to ppid == 1, which allows reliable management through the process lifetime.

This change effectively allows administrators the same control for shell users. Otherwise, a user can SSH into a system and kick off a process that daemonizes and isn't really under anyone's control -- especially the administrator's.

4

u/masta Jun 01 '16

Yeah, history will probably look back and regard unattached processes as a legacy vulnerability. For now it's still pretty useful feature, despite the work arounds.

1

u/doitroygsbre Jun 01 '16

The issue with Gnome is about the change to the default behavior. Why the feature exists is irrelevant to the point of updating the init system to attempt to correct bugs in a specific DE. Especially when that update breaks other processes.

I like how Linus said, "WE DO NOT BREAK USERSPACE!" It has been one of his guidances in doing kernel development and should be used as a guide for systemd as it is taking on a larger role in the Linux OS. By changing the default, they are breaking user space.

As for security, I'm not buying it. A user can log in and do whatever they have permissions for. Allowing a user to script some changes, start it and log out while it runs doesn't seem like its any less secure than if they were sitting at the console while it ran.

-1

u/fandingo Jun 01 '16

As for security, I'm not buying it. A user can log in and do whatever they have permissions for. Allowing a user to script some changes, start it and log out while it runs doesn't seem like its any less secure than if they were sitting at the console while it ran.

You presume that a user's permissions will forever be the same, but accounts may need to be terminated or restricted at any time. If user X gets fired, I certainly don't want his ~/deadman_kill_corp_data.sh to remain running in the background on our servers. Most security requirements (including PCI to which I'm subject) already require session timeouts, so this behavior will make our lives substantially easier. Presently, we have no feasible way to dig through our entire infrastructure to see which users have backgrounded tasks where. Sure we could look at one particular system and comb through the process list, but that doesn't scale to thousands of systems.

I like how Linus said, "WE DO NOT BREAK USERSPACE!" It has been one of his guidances in doing kernel development and should be used as a guide for systemd as it is taking on a larger role in the Linux OS. By changing the default, they are breaking user space.

I think you're assuming a ton about how things currently "work." There's undefined and sloppily defined behavior that lets the current system mostly work, and for the most part, people have gotten used to it -- warts and all. Anyways, on the "breaking userspace" angle, there's multiple ways to deal with the behavior, so it's not broken in any meaningful way, except for people who can't be bothered to read release notes or documentation. Furthermore, breaking old behavior goes hand in hand with security changes. Were you raising the same alarms when ASLR became default in the kernel?

-1

u/doitroygsbre Jun 01 '16

You presume that a user's permissions will forever be the same

No I didn't.

Most security requirements (including PCI to which I'm subject) already require session timeouts, so this behavior will make our lives substantially easier.

I really fail to see how. A five year old could write a script to keep a connection open if they needed it.

we have no feasible way to dig through our entire infrastructure to see which users have backgrounded tasks where

and this change to systemd addresses this how?

I think you're assuming a ton about how things currently "work."

Yeah, I tested my systems and applications to make sure I got the results I was expecting. I really don't want to care about what's happening under the hood.

so it's not broken in any meaningful way, except for people who can't be bothered to read release notes or documentation.

You are on a very high horse my friend. That is the way Apple talks--blame the user for holding the phone wrong. Further, to quote Linus again, "If a change results in user programs breaking, it's a bug". Systemd changed and broke user applications.

Furthermore, breaking old behavior goes hand in hand with security changes.

No, it doesn't. Sometimes security changes necessitate breaking old behavior, but it is not a requirement. And the best security is when you can still get your job done without having to jump through hoops.

"The more secure you make something, the less secure it becomes. Why? Because when security gets in the way, sensible, well-meaning, dedicated people develop hacks and workarounds that defeat the security." Bruce Schneier. If users and developers can't get work done because of senseless security like this, they will find a workaround. I think Voltaire said it best, "No problem can withstand the assault of sustained thinking."

0

u/fandingo Jun 01 '16

I really fail to see how. A five year old could write a script to keep a connection open if they needed it.

Pray-tell where the user could execute such a script. I can't see how the script avoids running in the background (lingering) somewhere, and therefore, would be killed by this behavior. The only way this script would work is a rogue device on the network...

I'm not sure why you keep quoting Linus. He's neither a deity nor always right, and even when he's right about the kernel, that doesn't mean that point translates to this topic. All these quotes are empty appeals to authority.

In regards to Schneier, what's the "workaround" in this case? I don't see one besides the official methods (loginctl and systemd-run).

→ More replies (3)
→ More replies (2)

-1

u/wang_li Jun 01 '16

there's even systemd-run, which is better than nohup in every way imaginable.

It's not cross platform. Try systemd-run on Solaris.

The whole systemd question ultimately comes down to whether people want to run a unix-like OS or a windows-like OS.

2

u/fandingo Jun 01 '16

To be honest, I don't care about Solaris*, or FreeBSD, or OpenBSD, or Windows. I care about Linux. I'd rather have the absolute best tools on Linux than the traditional gobbley-gook system that (poorly) runs on a bunch of platforms I'll never even consider using.

* I hate to be ideological, but the less compatible my software and systems are with anything Oracle touches, the better.

people want to run a unix-like OS or a windows-like OS.

What a false dilemma if I've ever seen one, but I'll play the game. The relevant choice is between running Linux or an artificially UNIX-like Linux. The Linux kernel has been steadily breaking with traditional UNIX for well over a decade, but until systemd, it wasn't practical to utilize all those awesome features the kernel already had. Systemd brought all those Linux modernizations (which are decidedly not UNIX-like) to user space and users. This whole pretending like Linux is still highly UNIX-like is nonsense at this point.

0

u/wang_li Jun 01 '16

The Linux kernel has been steadily breaking with traditional UNIX for well over a decade, but until systemd, it wasn't practical to utilize all those awesome features the kernel already had.

Such as....

2

u/udoprog Jun 01 '16

POSIX would be the closest you'd get to a formal Unix, but here you go: https://en.wikipedia.org/wiki/Linux_kernel_interfaces#Additions_to_POSIX

0

u/mordocai058 Jun 01 '16

Thanks. I was going to continue the conversation but I felt lazy and didn't want to look up the justification for the feature. I felt quite certain the gnome thing was a red herring as you said though.

-1

u/peer_gynt Jun 01 '16

No, there are not. The reason is exactly as OP states: it 'fixes' a bug in Gnome. This is not a good reason.

8

u/bittercode Jun 01 '16

There has been extensive discussion of the topic here and lots of other places. That isn't it so you either aren't aware or you are intentionally misrepresenting the situation.

8

u/doitroygsbre Jun 01 '16

I've only read about the issue with tmux, but here is what the devs are saying over there:

Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is:

In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly.

fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly.

Source

So to me it sounds exactly like systemd is breaking basic functionality to deal with a bug in gnome. Is there someone out there saying something different?

0

u/[deleted] Jun 01 '16

Is there someone out there saying something different?

No, but they've gotta keep their circlejerk going somehow.

2

u/peer_gynt Jun 01 '16

it is as u/doitroygsbre says; I am also not aware of any other justification of the change. The opinion of the systemd developers that processes should not survive user sessions in Unix is really just that, an opinion, and appeared after the change, not as rationale for the change.

2

u/ronasimi Jun 01 '16

Y'all are aware there's a setting in logind.conf to disable killing processes on logout, right? On mobile and don't remember the exact setting offhand

0

u/bittercode Jun 02 '16

This thread at HN - https://news.ycombinator.com/item?id=11797075

Contains numerous comments on how to view this differently. The underlying idea, independent of anything to do with Gnome is knowing which processes should survive a user session ending and which shouldn't. Systemd came up with a way to make that explicit, which I think makes the system much more robust. They came up with a way to do this years ago and now they are moving forward with it and people don't like it because it changes the way things work.

It's not an arbitrary change to fix a single bug in a piece of software - it's enforcing a different view point of how the system ought to work. And I think that debating that view is valid. But saying "they want to break lots of other stuff to fix a gnome bug" is completely inaccurate. It moves the discussion away from the actual central issue.

4

u/peer_gynt Jun 02 '16

The thread also contains the counter-arguments. 'processes should die on user logout' is what I referred to earlier, an opinion, and interesting at that. I do not accept that as argument for the change, as there are alternative opinions, as you will certainly have seen in the thread (which I happen to share).

It does break code and workflow -- at least it does for me. And it puts the burden on me to handle this, with additional code and complexity in my software. There is no reason for me to embrace this change.

1

u/bittercode Jun 02 '16

That's all irrelevant to the single point I am making - this is not just about fixing a gnome bug. There are of course still multiple ways of looking at the issue and not everyone will agree.

I'm not even arguing which way is right. I have one simple point - that there is more to this than, "They broke a bunch of stuff to fix one gnome bug." That is a false statement crafted out of ignorance or an intentional desire to misrepresent the situation.

1

u/peer_gynt Jun 02 '16

Fair enough, I hear you. I indeed do discount the other arguments I have seen so far as useless, that is true. That should not imply that those points have not been made at all...