Maybe I'm being naive, but I don't get how "pathnames as a concept are now utterly broken in POSIX". Isn't this "merely" a problem that the resolution of the path name is dynamic and can change between inspection and use? Wouldn't a practice of resolving pathnames once (recursively, atomically, whatever) into an immutable, opaque, direct handle, such as file descriptor, before use solve this issue? I realize what I just said may be tantamount to "all file io ops taking path strings are broken" - but that seems like a problem with the initial API design, not with the concept of having a level of indirection in path name resolution itself.
The trouble with symbolic links
81–90 of 126 posts
Re: The trouble with symbolic links
#82>Clients that have write access to the exported part of the file system under a share via SMB1 unix extensions or NFS can create symlinks that
So, it's not symlinks broken, but SMB1 unix extensions broken when exposed to the world for symlink creation. AIU this features doesn't even serve windows interoperability. And if the author wanted to disable all symlinks altogether, what is the purpose of these extensions?
Re: The trouble with symbolic links
#83I'm sorry symlinks are a thorn in Jeremy's side, but they are useful from a user's perspective. Hard links don't fill the same need. You can't normally hard link directories. If a file has multiple links, finding them all normally requires scanning the entire file system, so deleting a file now becomes harder. A file with multiple links doesn't have an obvious canonical path. As an example of all these issues, I mana…
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/ Not sure whether the pid issue was ever resolved, havn't checked in on that in a while.
Re: The trouble with symbolic links
#84Earlier quoted context omitted.
> You can't normally hard link directories. That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links? > If a file has multiple links, finding them all normally requires scanning the entire file system Couldn't this pretty easily be solved at the file syst…
Hard links don't have a canonical name though - they're all equally the same file, and this is really a problem: opening and editing a file in one location, edits it in all of them without you knowing what those locations might be. Symlinks at least explicitly declare the dependency and how it should mutate. A classic being /etc/resolve.conf symlinks - if I'm untarring and restore a symlink for it, I'm currently sayi…
Symlinks do that too even inevitably: no matter how you change the file, it changes at all links and you can't prevent it; systemd uses this feature when it creates dependency references (the linked dependency must never differ from the source, what hard links don't ensure).
Re: The trouble with symbolic links
#85Earlier quoted context omitted.
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 peop…
> 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 ha…
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.
Re: The trouble with symbolic links
#86Maybe I'm being naive, but I don't get how "pathnames as a concept are now utterly broken in POSIX". Isn't this "merely" a problem that the resolution of the path name is dynamic and can change between inspection and use? Wouldn't a practice of resolving pathnames once (recursively, atomically, whatever) into an immutable, opaque, direct handle, such as file descriptor, before use solve this issue? I realize what I j…
This is basically what I was going to say. The article spends a lot of time arguing that TOCTOU patterns introduce security vulnerabilities, which I think all programmers (should!) already know but then comes to the weird conclusion that we'd just be better off without symlinks instead of designing an API to work with them atomically.
Kinda reminds me of how a lot of UX changes happen: "This really popular feature is a bit kludgy and hard to maintain, let's just rewrite the whole app without it! (Instead of doing the work required to make it not suck.)"
Re: The trouble with symbolic links
#87Earlier quoted context omitted.
> You can't normally hard link directories. That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links? > If a file has multiple links, finding them all normally requires scanning the entire file system Couldn't this pretty easily be solved at the file syst…
Symlink loops are handled in the pathname resolution function in the kernel. Too many indirections of symlinks (typically around forty or so?) result in the resolution bailing with an ELOOP errno.
I at first read "errno" as "emo" and was trying to picture what that would look like.
Re: The trouble with symbolic links
#88Earlier quoted context omitted.
> 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 ha…
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.
> 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.
Re: The trouble with symbolic links
#89Maybe I'm being naive, but I don't get how "pathnames as a concept are now utterly broken in POSIX". Isn't this "merely" a problem that the resolution of the path name is dynamic and can change between inspection and use? Wouldn't a practice of resolving pathnames once (recursively, atomically, whatever) into an immutable, opaque, direct handle, such as file descriptor, before use solve this issue? I realize what I j…
This is basically what I was going to say. The article spends a lot of time arguing that TOCTOU patterns introduce security vulnerabilities, which I think all programmers (should!) already know but then comes to the weird conclusion that we'd just be better off without symlinks instead of designing an API to work with them atomically. Kinda reminds me of how a lot of UX changes happen: "This really popular feature is…
Almost all the TOCTOU examples given in the article could be modified not to involve symlinks and still be valid.
Re: The trouble with symbolic links
#90I personally think that hard links should go away. I have trouble thinking of any use for hard links that isn’t better served by CoW links. Hard links have quite surprising properties with respect to chmod, they are awkward to handle in archival tools, and even reliably identifying them is awkward to impossible in general.