1. 19
  1.  

  2. 9

    https.www.google.com.tedunangst.com. I like that.

    1. 3

      Maybe I haven’t noticed @tedu’s site in a while, but what’s with the redesign/subdomain?

      1. 6

        I can’t speak for @tedu but if I had to guess, it’s again a statement w.r.t. the CA model (and, in particular, Let’s Encrypt and/or other CAs that give you their blessing without checking if it’s a phishing attempt or such).

        “It kinda looks like a google page, it’s got www.google.com in the domain name, and it’s got the green padlock! Must be totally legit!”

    2. 2

      Is that magicless-fallback generally part of libc, or only in OpenBSD? For some reason I assumed the kernel did the fallback in that case.

      Also, why is it important that shell-scripts can be run, but shell-scripts without a #! cannot? Is it guarding against the case where an evildoer can chmod +x and append evil commands to a non-shell-script whose content the shell would naturally ignore?

      1. 4

        The magic fallback is a defined part of standard execvpe interface.

        It’s not particularly important. It’s a relic of the past where bits and pieces of “do what i want” snuck in. The shell, sh, should probably be just another command, but it’s kind of special, and then it was convenient to make it try interpreting x files without headers, and then people wanted every program to behave like the shell does.

        The net result of littering this feature around is that future compatibility is hard because you can’t really look at or change one piece of code in isolation.

        1. 1

          I don’t know, but if someone’s able to issue chmod +x successfully then can’t they just add a #! at the beginning of the script - whether it’s on disk or in memory?

          1. 1

            Adding +x requires permissions to write the directory inode, whereas adding #! requires write permissions to the file, so it is subtly different.

            1. 1

              Adding +x requires permissions to write the directory inode

              Huh? That’s not the case in any situation I can concoct…consider the existence of fchmod(2), for example.

          2. 1

            I can imagine a case where running certain files through certain shell interpreters, as opposed to a language’s interpreter, can be to the attacker’s advantage.