Hacker News Reader

Comment by adrianmonk | Hacker News Reader

> This computer stuff is amazingly complicated. I don't know how anyone gets anything done.

I wonder what could be done to make this type of problem less hidden and easier to diagnose.

The one thing that comes to mind is to have the loader fail fast. For security reasons, the loader needs to ensure TMPDIR isn't set. Right now it accomplishes this by un-setting TMPDIR, which leads to silent failures. Instead, it could check if TMPDIR is set, and if so, give a fatal error.

This would force you to unset TMPDIR yourself before you run a privileged program, which would be tedious, but at least you'd know it was happening because you'd be the one doing it.

(To be clear, I'm not proposing actually doing this. It would break compatibility. It's just interesting to think about alternative designs.)

View on HN

Then you'd have to add a wrapper script to su and similar programs that unsets all relevant environment variables. That set is not necessarily fixed; a future version of glibc may well require clearing NSS_FILES_hosts as well.

(This is about UNSECURE_ENVVARS, if someone needs to find the source location.)

Making these things more transparent is a good idea, of course, but it is somewhat hard. Maybe we could add Systemtap probes when environment variables are removed or ignored.

A related issue is that people stick LD_LIBRARY_PATH and LD_PRELOAD settings into shell profiles/login scripts and forget about them, leading to hard-to-diagnose failures. More transparency there would help, but again it's hard to see how to accomplish that.

Mh, I am starting to dislike this kind of hyper-configurability.

I know when this was necessary and used it myself quite a bit. But today, couldn't we just open up a mount namespace and bind-mount something else to /tmp, like SystemDs private tempdirs? (Which broke a lot of assumptions about tmpdirs and caused a bit of ruckus, but on the other hand, I see their point by now)

I'm honestly starting to wonder about a lot of these really weird, prickly and fragile environment variables which cause security vulnerabilities, if low-overhead virtualization and namespacing/containers are available. This would also raise the security floor.

> But today, couldn't we just open up a mount namespace and bind-mount something else to /tmp, like SystemDs private tempdirs?

No, because unless you're already root (in which case you wouldn't have needed the binary with the capability in the first place), you can't make a mount namespace without also making a user namespace, and the counterproductive risk-averse craziness has led to removing unprivileged users' ability to make user namespaces.

It's probably true that there are setuid programs that can be exploited if you run them in a user namespace. You probably need to remove setuid (and setgid) as Plan9 did in order to do this.

I meant distros are moving towards no unprivileged user namespaces at all, not just no setuid programs inside them.

Is "just no setuid programs inside them" even an option?

It is complex. There was another posting on HN where commenters were musing over why software projects have a much higher failure rate than any other engineering discipline.

Are we just shittier engineers, is it more complex, or is the culture such that we output lower quality? Does building a bridge require less cognitive load then a complex software project?

I think it's a cultural acceptance of lower quality, happily traded for deft execution, over and over.

We're better at encapsulating lower-level complexities in e.g. bridge building than we are at software.

All the complexities of, say, martensite grain boundaries and what-not are implicit in how we use steel to reinforce concrete. But we've got enough of it in a given project that the statistical summaries are adequate. It's a member with thus strength in tension, and thus in compression, and we put a 200% safety factor in and soldier on.

And nobody can take over the ownership of leftpad and suddenly falsify all our assumptions about how steel is supposed to act when we next deploy ibeam.js ...

The most well understood and dependable components of our electronic infrastructure are the ones we cordially loathe because they're composed in shudder COBOL, or CICS transactions, or whatever.

Exactly. The properties rarely matter outside the item. The column is of such-and-such a strength, that's it. But when things get strange we see failures. Perfect example: Challenger. Was the motor safe sitting on the pad? Yes. Was the motor safe in flight? Yes. Was the motor safe at ignition? On the test stand, yes. Stacked for launch, ignition caused the whole stack to twang--and maybe the seals failed....

> Are we just shittier engineers, is it more complex [...]

Both IMO: first, anybody could buy a computer during the last three decades, dabble in programming without learning basic concepts of software construction and/or user-interface design and get a job.

And copying bad libraries was (and is) easy. I still get angry when software tells me "this isn't a valid phone number" when I cut/copy/paste a number with a blank or a hyphen between digits. Or worse, libraries which expect the local part of an email address to only consist of alphanumeric characters and maybe a hyphen.

Second, writing software definitely is more complex than building physical objects. Because there are "no laws" of physics which limit what can be done. In the sense that physics tell you that you need to follow certain rules to get a stable building or a bridge capable of withstanding rain, wind, etc.

Absolutely. As an Electrical Engineer turned software guy, Ohm's/Kirchhoff's laws remain as valid and significant as when I was taught them 35 years ago. For software however, growth of hardware architectures/constraints made it possible to add much more functionality. My first UNIX experience was on PDP-11/44, where every process (and kernel) had access to an impressive maximum of 128K of RAM (if you figured out the flag to split address and data segments). This meant everything was simple and easy to follow: the UNIX permission model (user/group/other+suid/sgid) fit it well. ACLs/capabilities etc were reserved for VMS/Multics, with manuals spanning shelves.

Given hardware available to an average modern Linux box, it is hardly surprising that these bells and whistles were added - someone will find them useful in some scenarios and additional resource is negligible. It does however make understanding the whole beast much, much harder...

It's just that people are somewhat rational.

There are no big wins left in bridge building, so there is no justification for taking big risks. Also, in most software project failures, the only cost is people's time; no animals are harmed, no irreplaceable antique guitars are smashed, no ecosystems are damaged, and no buses of schoolchildren plunge screaming into an abyss.

Your software startup didn't get funded? Well, you can go back and finish college.

I write some software to automate some engineering processes in construction.

I'd say it comes from some of (order of most to least imo, but I'm only mid level so take what I say accordingly):

* physical processes have a fuzzy good enough. The bridge stands with thrice its expected max load. It is good enough.

* most software doesn't have life safety behind it. In construction, life safety systems receive orders of magnitude more scrutiny.

* physical projects don't have more than 20 different interdependencies; there's an upper limit on arbitrary complexity

* physical projects usually have clearish deadlines (they lie, but by a constant factor)

* The industries are old enough that they check juniors before they give them big decisions.

* Similarly, there exists PE accountability in construction

Yeah, this case is a good example of why many people don't like linux. Too much interconnected stuff that can go wrong.

Reply on news.ycombinator.com