4 ms·

How common is this technique for loading libraries? How about in the kind of POSIX tools that are available, but not exclusive to, on mac os (sucha as bash, ter

How common is this technique for loading libraries? How about in the kind of POSIX tools that are available, but not exclusive to, on mac os (sucha as bash, termux, vim, git, apache etc)?

zaarn 6y ago
The old code checks for the filepath to be present before attempting to dlopen it. The new way requires you to dlopen the path. This is very meh because dlopen already executes code from the library, so if you didn't want that, good luck. (glibc and some other core libs like openssl like to detect plugins by probing the paths for libs and only loading them when necessary)
- afandian 6y ago
  Yeah. So I understand it has been considered best practice to check the file before opening it? Does that mean we can assume that most well-written programs will follow the pattern and break on mac os? I would have thought that even if Apple did make this change they could trap the fopen or whatever and return something useful based on a heuristic? It wouldn't be the first time that they put exceptions and heuristics in for software compatibility.
  - chrisseaton 6y ago
    > So I understand it has been considered best practice to check the file before opening it? Check it... for what?
    - coldtea 6y ago
      For presence...
      - chrisseaton 6y ago
        Why do you need to separately check for presence before you use dlopen? If it's not there dlopen will give you a nice error message - no need to check yourself. Are you currently checking files are there before you dlopen them? How do you avoid a race between the stat and the dlopen? What happens if the file is removed between them? Seems broken and you shouldn't be doing this in the first place.
        zaarn 6y ago
        It is usually unlikely that a file will be removed between stat and dlopen, such errors occur rarely. Even more rarely when the file happens to be a systems lib or plugin lib. Some errors occur rarely enough that it isn't worth worrying about.
  - unilynx 6y ago
    It has never been good practice to check before open - open first, then check. And if you're creating a file, use exclusive mode, don't check first. You're opening yourself up to a lot of race conditions otherwise, and this has been the source of many security vulnerabilities
jdub 6y ago
NON-system libraries? Lots. e.g. reading through a directory of dynamically loadable plugins System libraries (depending how Apple defines that)? Unusual.
lultimouomo 6y ago
I would expect this to impact mainly build systems, and I would expect to impact them really hard. But to be honest this is just a gut feeling. On the other hand, I am sure that Apple has thought this through, as we all know developer experience is of paramount importance for them.

How common is this technique for loading libraries? How about in the kind of POSIX tools that are available, but not exclusive to, on mac os (sucha as bash, termux, vim, git, apache etc)?

zaarn 6y ago

The old code checks for the filepath to be present before attempting to dlopen it. The new way requires you to dlopen the path. This is very meh because dlopen already executes code from the library, so if you didn't want that, good luck. (glibc and some other core libs like openssl like to detect plugins by probing the paths for libs and only loading them when necessary)

afandian 6y ago
Yeah. So I understand it has been considered best practice to check the file before opening it? Does that mean we can assume that most well-written programs will follow the pattern and break on mac os? I would have thought that even if Apple did make this change they could trap the fopen or whatever and return something useful based on a heuristic? It wouldn't be the first time that they put exceptions and heuristics in for software compatibility.
- chrisseaton 6y ago
  > So I understand it has been considered best practice to check the file before opening it? Check it... for what?
  - coldtea 6y ago
    For presence...
    - chrisseaton 6y ago
      Why do you need to separately check for presence before you use dlopen? If it's not there dlopen will give you a nice error message - no need to check yourself. Are you currently checking files are there before you dlopen them? How do you avoid a race between the stat and the dlopen? What happens if the file is removed between them? Seems broken and you shouldn't be doing this in the first place.
      - zaarn 6y ago
        It is usually unlikely that a file will be removed between stat and dlopen, such errors occur rarely. Even more rarely when the file happens to be a systems lib or plugin lib. Some errors occur rarely enough that it isn't worth worrying about.
- unilynx 6y ago
  It has never been good practice to check before open - open first, then check. And if you're creating a file, use exclusive mode, don't check first. You're opening yourself up to a lot of race conditions otherwise, and this has been the source of many security vulnerabilities

jdub 6y ago

NON-system libraries? Lots. e.g. reading through a directory of dynamically loadable plugins System libraries (depending how Apple defines that)? Unusual.

lultimouomo 6y ago

I would expect this to impact mainly build systems, and I would expect to impact them really hard. But to be honest this is just a gut feeling. On the other hand, I am sure that Apple has thought this through, as we all know developer experience is of paramount importance for them.