Systemd Reverts Its Stance On Letting Users Access Frame-Buffer Devices

[phoronix]

Phoronix: Systemd Reverts Its Stance On Letting Users Access Frame-Buffer Devices

Last week's release of systemd 230 ended up shipping with a change that made it more easy for processes running as a user to snoop on frame-buffer devices. That change has already been reverted for the next systemd update...

http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Reverts-FBDEV-Change

[chuckula]

Can we have a flamefest where the SystemD haters scream about how SystemD intentionally broke security in release 230 because NSA BACKDOOR followed by the same posters complaining that SystemD has taken away useful functionality in the followup release because SystemD developers hate users?

[stefansaraev]

no. we better not, and it is systemd btw, not SystemD

[arokh]

Or sÿstëmd on high holidays.

[doublez13]

Call me crazy but the more I read about the Systemd philosophy, the more I love it.

[GraysonPeddie]

At least I'm still running systemd ver. 229-3 in Arch Linux.

[sjukfan]

If they did this more often than "Working as intended. Ticket closed." I think less people would complain.

[RahulSundaram]

If they did this more often than "Working as intended. Ticket closed." I think less people would complain.

You can't expect a large scale project to agree with every ticket that is filed. Maintainers must have the option of saying no if they believe it doesn't fit into how they want to do things. I rather see less reverts of changes and more thought into not accepting such changes in the first place.

[starshipeleven]

If they did this more often than "Working as intended. Ticket closed." I think less people would complain.

If people read TFM there would be less of such tickets, probably.

[Vax456]

I don't have that much of a beef with systemd, but I'd be lying if I said I didn't worry about using it. For example, after an update to one of my CentOS boxes, Tomcat wouldn't start from systemd. The journald logs were littered with "Could not find class $JAVA_OPTS" messages. Turns out that variable's are not expanded in EnvironmentFile declarations, and my Tomcat config was littered with JAVA_OPTS="$JAVA_OPTS ..." declarations. Variable expansion has never been supported in systemd. The part that worries me is if variable expansion was never supported, how were the variables getting expanded this whole time until the last update?

So yeah, there's updates for closing security holes, and there's updates for fixing some goof. Someone will always find a way to rely on a bug, and when its fixed, be prepared for the shitstorm that's to come.