11 ms·

"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is b

by mongol 4y ago

"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is broken. If something works as intended, but its utility is limited, and it can be improved, it is not broken.

joosters 4y ago
Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code. You can play with your words and redefine their meanings, but the vulnerabilities remain.
- mongol 4y ago
  They have been around for 40+ years, they don't break code unless we are talking about code predating their introduction. It is not me playing with words, I am just pointing out a tired trope.
- rob_c 4y ago
  > but they cause a lot of unintended security vulnerabilities No, bad coders on UNIX platforms do this. The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022. Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
  - joosters 4y ago
    Don't victim blame. Do you really think that using open(), stat(), lstat() (!), realpath(), mkdir(), rename() etc etc etc is a sign of a bad coder? The problem is that the APIs set you up for unexpected failure, and even some of the provided workarounds to 'safely' handle symlinks don't do it well enough. In the case of symlinks, I think it's fair to blame the tools rather than the workman.
    - zx8080 4y ago
      API is always simplification and is not supposed to be used without understanding concepts and reality under the hood. Example: wanna show 1M POI in browser on some small territory. Openmaps/googlemaps API allows that, no prob. Looks good, yeah? Sorry, doesn't work. Because 1M is too large to show and browser gets stuck. The API do not prevent _all_ kinds of legshooting engineers invent.
      - rob_c 4y ago
        Don't worry, they don't listen to speaking out against bigG or others for being bad
    - rob_c 4y ago
      This is not victim blame. RTFM READ IT!!! Most sane languages and low level tools describe what you want and how to work correctly. If you don't want this feature in the filesystem, move to one that doesn't support it, or better yet submit a patch to run the filesytem you want with this feature deactivted for "security concerns". Demanding a whole OS change the way it works for bad/lazy/inept coders is akin to 2 people getting blind drunk and blaming the other person or the drink for the stupid things they did. Take some responsibility.
      - com2kid 4y ago
        > Demanding a whole OS change the way it works for bad/lazy/inept coders is akin to 2 people getting blind drunk and blaming the other person or the drink for the stupid things they did. Take some responsibility. And if people were just more careful, none of rust's memory safety stuff is needed! Also, why do modern languages hand hold multi-threading so much, just give developers some mutex primitives and let them have at it, the good coders will be just fine! Of course the rest of us will have to deal with machines getting pwned due to security bugs, but hey, at least the "well written" programs won't have those problems...
        rob_c 4y ago
        Stop defending poor coding and lack of skill. Everything you're saying is an excusory situation for hiring poor coders at minimum wage who can't or won't read documentation. This is 80IQ points South of frankly most of the conversations on here. Yes the rest of us cope with security incidents. There will always be security incidents. Stop defending practices that leads to them.
  - the8472 4y ago
    Part of the problem is that handles on directories on which one can then use the the *at family of syscalls are not first-class citizens in many programming languages. Which in turn might be due to portability concerns with windows, e.g. Java's SecureDirectoryStream isn't available there[0]. Apparently windows does have an openat-like API[1], but it's low-level. Programmers aren't using them because the language standard libraries point them in the wrong direction. [0] https://github.com/google/guava/wiki/Release21#user-content-commonio https://github.com/google/guava/wiki/Release21#user-content-... [1] https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a04957d86cfd191fcd78/library/std/src/sys/windows/fs.rs#L711-L715 https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a...
    - ziml77 4y ago
      Weird that you need to dip down to an Nt* function to open a child given a parent handle. It's not like it's unheard of to be able to do that in the Windows API. The registry is also a hierarchical system and opening any key requires passing in a parent key handle (the root handles are predefined).
      - ChrisSD 4y ago
        It's a quirk of history, imho. If Win32 had been written without concern for what came before, it probably would have more closely followed NT conventions. But it wasn't. It followed on from Win16 and DOS so, to an extent, it emulated DOS-style path and file handling. After all, that's what developers and users were familiar with. The Windows registry did not have all this baggage so it followed the style of the NT kernel. Though this doesn't explain why Win32 never added CreateFileRelativeToDirectoryHandleW
    - rob_c 4y ago
      This a serious issue in support of the language for running on a UNIX system. Frankly blaming the kernel/filesystem for this is like saying I want my 720p monitor to display 8k correctly, it must be the display-drivers fault...
- pif 4y ago
  > they break lots of otherwise-functioning code. There is no otherwise! POSIX has symbolic links: if your software does not function with symbolic links, it does not function on POSIX.
  - IshKebab 4y ago
    Of course there is otherwise. Windows (more or less) doesn't have symlinks. Plan9 doesn't have symlinks. You don't have to have symlinks. Can you not imagine anything other than POSIX?
- indymike 4y ago
  > You can play with your words and redefine their meanings, but the vulnerabilities remain. I don't think OP was trying to play with words, I do think there's an absolute "this symlink thing is a vuln" vs an absolute "I use symlinks to make X work" argument. Symlinks have always been at the line between the absolutes. They do enable a great deal of functionality but they can be a security risk, and source of bugs when developers don't handle them correctly. That said, they are heavily used feature on unix like oses. My /usr/bin on Ubuntu has 48 of them (most were put there by apt installed packages).
- deleted 4y ago
  [deleted]
littlestymaar 4y ago
That “X − designed in the 70s when we had no idea of anything regarding computers − is fundamentally broken” isn't so surprising after all. In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it. I don't like breaking everything all the time more than anyone, but maybe one time every 20 or 30 years is OK…
- SiempreViernes 4y ago
  I take it that here "technology landscape" means something like "the gui portion of the software stack", right?
- Beltalowda 4y ago
  > In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it. Bridges and buildings from the 1970s (and much older) are still working fine today. The thing is, if I do decide to replace my bridge or building because it's old and outdated then I can just replace that one thing without affecting much else. With computers, that is obviously not the case: you need to replace the entire city. Plus, it's not really the case that we "keep using almost unmodified stuff from the 70s"; while many concepts remained the same and things remained compatible, things have been greatly extended and modified since; it's like those old buildings that were built during the middle ages (or sometimes even earlier) that have been changed and upgraded extensively throughout the centuries to the point you really need to know where to look to see it's actually a centuries-old building.
  - Shorel 4y ago
    It would be like upgrading the train network to increase the distance between rails, to increase the size of cargo that can be transported. Not just one city needs the upgrade, all of them will need it, and all the related infrastructure like bridges and tunnels too.
  - 4y ago
3pt14159 4y ago
The word "broken" came from before we had constant arms races in technology. Obviously we don't call clubs broken because we now have rapid artillery, but there was enough time between clubs and swords, and swords and guns to allow transitions away. When I'm exposed to a core OS feature I expect by default that it should not come with expected, critical security vulnerabilities. It is rational to expect a user to use the basic features of an OS and expect them not to cause severe issues. You can say it's not broken, and that's true in as much as they're still functional, but if by broken one means the larger question of "is this reliable and safe?" then I think the answer is pretty clear that symlinks are broken.
- ploxiln 4y ago
  In the modern world, the demand seems to be that every tool be perfectly safe in every situation no matter what you do (and it seems practically nothing lives up to this demand, given the ever increasing river of silly CVEs for almost every component, like regex DoS on build tools). It's important to understand the scope of the issue. If you create and operate on your own symlinks in your own folders, there is no problem. The problem is when a more privileged user operates on folders that can be written to by less privileged users, for example system daemons (like a /tmp cleanup, or a web server serving /home/*/www), or suid binaries. These things need to be written very carefully, it is now clear. But if I'm working with my own files, media, source code, build tools, web pages, etc, in my own folders, then symlinks are still fine. And there is an existing setting to mitigate a couple common forms of the issue that does exist when accessing folders other users can write to: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs.html#protected-symlinks https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs...
  - seoaeu 4y ago
    > In the modern world, the demand seems to be that every tool be perfectly safe in every situation no matter what you do The problem is that there is such a huge number of tools in widespread use that each one causing even a few security vulnerabilities means that the ecosystem overall is constantly vulnerable
  - 4y ago
nine_k 4y ago
If it used to work without letting others pwn your account or box, and not it fails to, it's broken.

by mongol 4y ago

joosters 4y ago

Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code. You can play with your words and redefine their meanings, but the vulnerabilities remain.

mongol 4y ago
They have been around for 40+ years, they don't break code unless we are talking about code predating their introduction. It is not me playing with words, I am just pointing out a tired trope.
rob_c 4y ago
> but they cause a lot of unintended security vulnerabilities No, bad coders on UNIX platforms do this. The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022. Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
- joosters 4y ago
  Don't victim blame. Do you really think that using open(), stat(), lstat() (!), realpath(), mkdir(), rename() etc etc etc is a sign of a bad coder? The problem is that the APIs set you up for unexpected failure, and even some of the provided workarounds to 'safely' handle symlinks don't do it well enough. In the case of symlinks, I think it's fair to blame the tools rather than the workman.
  - zx8080 4y ago
    API is always simplification and is not supposed to be used without understanding concepts and reality under the hood. Example: wanna show 1M POI in browser on some small territory. Openmaps/googlemaps API allows that, no prob. Looks good, yeah? Sorry, doesn't work. Because 1M is too large to show and browser gets stuck. The API do not prevent _all_ kinds of legshooting engineers invent.
    - rob_c 4y ago
      Don't worry, they don't listen to speaking out against bigG or others for being bad
  - rob_c 4y ago
    This is not victim blame. RTFM READ IT!!! Most sane languages and low level tools describe what you want and how to work correctly. If you don't want this feature in the filesystem, move to one that doesn't support it, or better yet submit a patch to run the filesytem you want with this feature deactivted for "security concerns". Demanding a whole OS change the way it works for bad/lazy/inept coders is akin to 2 people getting blind drunk and blaming the other person or the drink for the stupid things they did. Take some responsibility.
    - com2kid 4y ago
      > Demanding a whole OS change the way it works for bad/lazy/inept coders is akin to 2 people getting blind drunk and blaming the other person or the drink for the stupid things they did. Take some responsibility. And if people were just more careful, none of rust's memory safety stuff is needed! Also, why do modern languages hand hold multi-threading so much, just give developers some mutex primitives and let them have at it, the good coders will be just fine! Of course the rest of us will have to deal with machines getting pwned due to security bugs, but hey, at least the "well written" programs won't have those problems...
      - rob_c 4y ago
        Stop defending poor coding and lack of skill. Everything you're saying is an excusory situation for hiring poor coders at minimum wage who can't or won't read documentation. This is 80IQ points South of frankly most of the conversations on here. Yes the rest of us cope with security incidents. There will always be security incidents. Stop defending practices that leads to them.
- the8472 4y ago
  Part of the problem is that handles on directories on which one can then use the the *at family of syscalls are not first-class citizens in many programming languages. Which in turn might be due to portability concerns with windows, e.g. Java's SecureDirectoryStream isn't available there[0]. Apparently windows does have an openat-like API[1], but it's low-level. Programmers aren't using them because the language standard libraries point them in the wrong direction. [0] https://github.com/google/guava/wiki/Release21#user-content-commonio https://github.com/google/guava/wiki/Release21#user-content-... [1] https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a04957d86cfd191fcd78/library/std/src/sys/windows/fs.rs#L711-L715 https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a...
  - ziml77 4y ago
    Weird that you need to dip down to an Nt* function to open a child given a parent handle. It's not like it's unheard of to be able to do that in the Windows API. The registry is also a hierarchical system and opening any key requires passing in a parent key handle (the root handles are predefined).
    - ChrisSD 4y ago
      It's a quirk of history, imho. If Win32 had been written without concern for what came before, it probably would have more closely followed NT conventions. But it wasn't. It followed on from Win16 and DOS so, to an extent, it emulated DOS-style path and file handling. After all, that's what developers and users were familiar with. The Windows registry did not have all this baggage so it followed the style of the NT kernel. Though this doesn't explain why Win32 never added CreateFileRelativeToDirectoryHandleW
  - rob_c 4y ago
    This a serious issue in support of the language for running on a UNIX system. Frankly blaming the kernel/filesystem for this is like saying I want my 720p monitor to display 8k correctly, it must be the display-drivers fault...
pif 4y ago
> they break lots of otherwise-functioning code. There is no otherwise! POSIX has symbolic links: if your software does not function with symbolic links, it does not function on POSIX.
- IshKebab 4y ago
  Of course there is otherwise. Windows (more or less) doesn't have symlinks. Plan9 doesn't have symlinks. You don't have to have symlinks. Can you not imagine anything other than POSIX?
indymike 4y ago
> You can play with your words and redefine their meanings, but the vulnerabilities remain. I don't think OP was trying to play with words, I do think there's an absolute "this symlink thing is a vuln" vs an absolute "I use symlinks to make X work" argument. Symlinks have always been at the line between the absolutes. They do enable a great deal of functionality but they can be a security risk, and source of bugs when developers don't handle them correctly. That said, they are heavily used feature on unix like oses. My /usr/bin on Ubuntu has 48 of them (most were put there by apt installed packages).
deleted 4y ago
[deleted]

littlestymaar 4y ago

That “X − designed in the 70s when we had no idea of anything regarding computers − is fundamentally broken” isn't so surprising after all. In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it. I don't like breaking everything all the time more than anyone, but maybe one time every 20 or 30 years is OK…

SiempreViernes 4y ago
I take it that here "technology landscape" means something like "the gui portion of the software stack", right?
Beltalowda 4y ago
> In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it. Bridges and buildings from the 1970s (and much older) are still working fine today. The thing is, if I do decide to replace my bridge or building because it's old and outdated then I can just replace that one thing without affecting much else. With computers, that is obviously not the case: you need to replace the entire city. Plus, it's not really the case that we "keep using almost unmodified stuff from the 70s"; while many concepts remained the same and things remained compatible, things have been greatly extended and modified since; it's like those old buildings that were built during the middle ages (or sometimes even earlier) that have been changed and upgraded extensively throughout the centuries to the point you really need to know where to look to see it's actually a centuries-old building.
- Shorel 4y ago
  It would be like upgrading the train network to increase the distance between rails, to increase the size of cargo that can be transported. Not just one city needs the upgrade, all of them will need it, and all the related infrastructure like bridges and tunnels too.
- 4y ago

3pt14159 4y ago

The word "broken" came from before we had constant arms races in technology. Obviously we don't call clubs broken because we now have rapid artillery, but there was enough time between clubs and swords, and swords and guns to allow transitions away. When I'm exposed to a core OS feature I expect by default that it should not come with expected, critical security vulnerabilities. It is rational to expect a user to use the basic features of an OS and expect them not to cause severe issues. You can say it's not broken, and that's true in as much as they're still functional, but if by broken one means the larger question of "is this reliable and safe?" then I think the answer is pretty clear that symlinks are broken.

ploxiln 4y ago
In the modern world, the demand seems to be that every tool be perfectly safe in every situation no matter what you do (and it seems practically nothing lives up to this demand, given the ever increasing river of silly CVEs for almost every component, like regex DoS on build tools). It's important to understand the scope of the issue. If you create and operate on your own symlinks in your own folders, there is no problem. The problem is when a more privileged user operates on folders that can be written to by less privileged users, for example system daemons (like a /tmp cleanup, or a web server serving /home/*/www), or suid binaries. These things need to be written very carefully, it is now clear. But if I'm working with my own files, media, source code, build tools, web pages, etc, in my own folders, then symlinks are still fine. And there is an existing setting to mitigate a couple common forms of the issue that does exist when accessing folders other users can write to: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs.html#protected-symlinks https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs...
- seoaeu 4y ago
  > In the modern world, the demand seems to be that every tool be perfectly safe in every situation no matter what you do The problem is that there is such a huge number of tools in widespread use that each one causing even a few security vulnerabilities means that the ecosystem overall is constantly vulnerable
- 4y ago

nine_k 4y ago

If it used to work without letting others pwn your account or box, and not it fails to, it's broken.