3 ms·

symlinks are great, I don't see why we would remove such feature. The author pointed out a bunch of issues around atomic operations related to symlinks which in

symlinks are great, I don't see why we would remove such feature. The author pointed out a bunch of issues around atomic operations related to symlinks which in my view are valid. Similar TOCTOU race exists with PIDs, see https://lwn.net/Articles/773459/ https://lwn.net/Articles/773459/ Not sure whether the pid issue was ever resolved, havn't checked in on that in a while.

GoblinSlayer 4y ago
https://man7.org/linux/man-pages/man2/pidfd_open.2.html https://man7.org/linux/man-pages/man2/pidfd_open.2.html
IshKebab 4y ago
Symlinks are great from a "just make it work!" point of view but they're absolutely terrible from a "make it robust, sane and secure" point of view. All of the points in the article are valid but there's even simpler stuff like the fact that you can't canonicalise paths (resolve ..) without reading the filesystem. This should be required reading: https://9p.io/sys/doc/lexnames.html https://9p.io/sys/doc/lexnames.html
- kazinator 4y ago
  You can resolve some .. components without reading the filesystem and there are situations where it is useful to do that, while refusing to treat .. that cannot be resolved without accessing the filesystem. One example is inside the implementation of a function that calculates relative paths: 1> (rel-path "a/b" "../c") "../../../c" 2> (rel-path "../c" "a/b") ** rel-path: from path uses .. to escape common prefix: "../c" "a/b" ** during evaluation at expr-2:1 of form (rel-path "../c" "a/b") The relative path from ../c to a/b cannot be calculated as a pure function of just the two strings, because we do not know what the current directory is called in the .. parent; that would require searching the file system. The function is very useful with this restriction, which can be externally worked around if ever necessary, e.g. by tacking the absolute path of the current directory onto both arguments: 3> (rel-path `@(pwd)/../c` `@(pwd)/a/b`) "../kaz/a/b"
  - IshKebab 4y ago
    That's not really resolving .. though is it? You need both the original path and the output of this function, and one of them always still has .. in it. Interesting nonetheless; thanks.
    - kazinator 4y ago
      It does; for instance: 2> (rel-path "a/../b/../c/.." "f/../g") "g"

GoblinSlayer 4y ago

https://man7.org/linux/man-pages/man2/pidfd_open.2.html https://man7.org/linux/man-pages/man2/pidfd_open.2.html

IshKebab 4y ago

Symlinks are great from a "just make it work!" point of view but they're absolutely terrible from a "make it robust, sane and secure" point of view. All of the points in the article are valid but there's even simpler stuff like the fact that you can't canonicalise paths (resolve ..) without reading the filesystem. This should be required reading: https://9p.io/sys/doc/lexnames.html https://9p.io/sys/doc/lexnames.html

kazinator 4y ago
You can resolve some .. components without reading the filesystem and there are situations where it is useful to do that, while refusing to treat .. that cannot be resolved without accessing the filesystem. One example is inside the implementation of a function that calculates relative paths: 1> (rel-path "a/b" "../c") "../../../c" 2> (rel-path "../c" "a/b") ** rel-path: from path uses .. to escape common prefix: "../c" "a/b" ** during evaluation at expr-2:1 of form (rel-path "../c" "a/b") The relative path from ../c to a/b cannot be calculated as a pure function of just the two strings, because we do not know what the current directory is called in the .. parent; that would require searching the file system. The function is very useful with this restriction, which can be externally worked around if ever necessary, e.g. by tacking the absolute path of the current directory onto both arguments: 3> (rel-path `@(pwd)/../c` `@(pwd)/a/b`) "../kaz/a/b"
- IshKebab 4y ago
  That's not really resolving .. though is it? You need both the original path and the output of this function, and one of them always still has .. in it. Interesting nonetheless; thanks.
  - kazinator 4y ago
    It does; for instance: 2> (rel-path "a/../b/../c/.." "f/../g") "g"