A remotely exploitable hole in bash

Posted Sep 26, 2014 16:59 UTC (Fri) by raven667 (subscriber, #5198)
In reply to: A remotely exploitable hole in bash by bronson
Parent article: A remotely exploitable hole in bash

> I don't see any way the benefit of the feature can outweigh all this effort.

This is an instance of what is a hard and fast rule in the kernel, "Don't Break Userspace(tm)" It doesn't matter how dumb the feature is in retrospect, it has to continue working even after you refactor the implementation, someone out there could be depending on it, probably without even being aware of it.

A remotely exploitable hole in bash

Posted Sep 27, 2014 23:28 UTC (Sat) by bronson (subscriber, #4806) [Link] (2 responses)

Nah, features get removed after deprecation periods, even in the Linux Kernel. Can you imagine being burdened with devfs forever?

A remotely exploitable hole in bash

Posted Sep 28, 2014 4:25 UTC (Sun) by raven667 (subscriber, #5198) [Link] (1 responses)

devfs may not be there but /dev certainly is which is the user facing API. There is no attempt at internal kernel API stability so how things get done are constantly in flux (devfs vs. udev vs. static /dev) but the syscall interface and even /proc and /dev are maintained so that old software can continue to run.

A remotely exploitable hole in bash

Posted Sep 28, 2014 7:25 UTC (Sun) by bronson (subscriber, #4806) [Link]

Not sure what you're arguing... Don't you remember all the breakage reports caused by the devfs removal? And Greg KH's unapologetic emails? (IMO rightfully so, good times) If not, no big deal, there are other user-visible deprecations to be found in feature-removal-schedule.txt.

Linux's backward compatibility is nothing short of stellar. It's part of what makes using Linux such a pleasure. But, on the rare occasion that a mistake is made, we don't have to live with it forever. It can be fixed.