4 ms·

> 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 hidde

> 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.)

tetha 11mo ago
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.
- josephcsible 11mo ago
  > 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.
  - kragen 11mo ago
    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.
    - josephcsible 11mo ago
      I meant distros are moving towards no unprivileged user namespaces at all, not just no setuid programs inside them.
      - kragen 11mo ago
        Is "just no setuid programs inside them" even an option?
ericmcer 11mo ago
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?
- rout39574 11mo ago
  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.
  - LorenPechtel 11mo ago
    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....
- jcynix 11mo ago
  > 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.
LorenPechtel 11mo ago
Yeah, this case is a good example of why many people don't like linux. Too much interconnected stuff that can go wrong.
fweimer 11mo ago
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.

tetha 11mo ago

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.

josephcsible 11mo ago
> 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.
- kragen 11mo ago
  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.
  - josephcsible 11mo ago
    I meant distros are moving towards no unprivileged user namespaces at all, not just no setuid programs inside them.
    - kragen 11mo ago
      Is "just no setuid programs inside them" even an option?

ericmcer 11mo ago

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?

rout39574 11mo ago
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.
- LorenPechtel 11mo ago
  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....
jcynix 11mo ago
> 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.

LorenPechtel 11mo ago

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

fweimer 11mo ago

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.