28 ms·

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

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.
    - com2kid 4y ago
      > Stop defending poor coding and lack of skill. This is a hopelessly elitist attitude. Also it is a useless one, over 1000 CVEs, yelling "be better at your job!" is just going to result in another 1000 CVEs. That is exactly what happened for decades with buggy C code, buffer overflows and use after frees, for a long time the refrain was "just do better!". Well millions of dollars of damages later, it turns out berating people to "just do better" doesn't actually make things any better. A combination of static analysis and runtime tooling, and then the eventual creation of new programming languages that allow for correct modeling of memory ownership, is what the industry en masse has decided on. For APIs that get misused? The solution is to provide higher level APIs that allow programmers to easily accomplish the correct thing in a secure manner. As an aside, and in general, when designing software, I want to maximize the amount of brain power I am dedicating to solving the business problem at hand. Dealing with poorly designed insecure APIs detracts from me getting my actual job done. > Stop defending practices that leads to them. The practice in this case is the direct use of filesystem APIs that were designed in the 1970s for a very different security ecosystem than what exists today. Lots of things designed in the 1970s are not secure by default. Heck most things designed in the 1970s, outside of maybe some IBM Mainframe stuff, was not designed to be secure by default. What you are arguing is that instead of buying a fire extinguisher to put in the kitchen of an old house, people should just try and not set things on fire. I mean, yeah, sure, good goal, but buy the fire extinguisher anyway.
      - rob_c 4y ago
        How is it hopelessly elitist to call out insecure code as being INSECURE!!! My whole point is the same as yours fix it at the source. You seem to think hacking off the hands of some coders is safer (I may agree). But why not try to EDUCATE THEM?!? Education costs 1000s of dollars at most rather than your hypothetical billion dollar APPLICATION LEVEL hack. Why are you so elitist to assume people can't cope with these concepts? My whole point is that they need to be tought they're running on a Unix server rather than an 1998 SD card. The rest of your complaining is either you don't understand this or are trying to excuse bad or insecure practice as acceptable. If this is your case. RUN THE CODE IN AN ENVIRONMENT WHERE THIS CAN'T HAPPEN. Seriously there are filesystems and options for this. Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough.

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.
  - com2kid 4y ago
    > Stop defending poor coding and lack of skill. This is a hopelessly elitist attitude. Also it is a useless one, over 1000 CVEs, yelling "be better at your job!" is just going to result in another 1000 CVEs. That is exactly what happened for decades with buggy C code, buffer overflows and use after frees, for a long time the refrain was "just do better!". Well millions of dollars of damages later, it turns out berating people to "just do better" doesn't actually make things any better. A combination of static analysis and runtime tooling, and then the eventual creation of new programming languages that allow for correct modeling of memory ownership, is what the industry en masse has decided on. For APIs that get misused? The solution is to provide higher level APIs that allow programmers to easily accomplish the correct thing in a secure manner. As an aside, and in general, when designing software, I want to maximize the amount of brain power I am dedicating to solving the business problem at hand. Dealing with poorly designed insecure APIs detracts from me getting my actual job done. > Stop defending practices that leads to them. The practice in this case is the direct use of filesystem APIs that were designed in the 1970s for a very different security ecosystem than what exists today. Lots of things designed in the 1970s are not secure by default. Heck most things designed in the 1970s, outside of maybe some IBM Mainframe stuff, was not designed to be secure by default. What you are arguing is that instead of buying a fire extinguisher to put in the kitchen of an old house, people should just try and not set things on fire. I mean, yeah, sure, good goal, but buy the fire extinguisher anyway.
    - rob_c 4y ago
      How is it hopelessly elitist to call out insecure code as being INSECURE!!! My whole point is the same as yours fix it at the source. You seem to think hacking off the hands of some coders is safer (I may agree). But why not try to EDUCATE THEM?!? Education costs 1000s of dollars at most rather than your hypothetical billion dollar APPLICATION LEVEL hack. Why are you so elitist to assume people can't cope with these concepts? My whole point is that they need to be tought they're running on a Unix server rather than an 1998 SD card. The rest of your complaining is either you don't understand this or are trying to excuse bad or insecure practice as acceptable. If this is your case. RUN THE CODE IN AN ENVIRONMENT WHERE THIS CAN'T HAPPEN. Seriously there are filesystems and options for this. Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough.