Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The trouble with symbolic links

lwn.net

Post reply on HN
Print view View original

61–70 of 126 posts

Re: The trouble with symbolic links

#61

Post by Shorel »

Beltalowda wrote: post #33
littlestymaar wrote: post #9

Earlier quoted context omitted.

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…

> 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…

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.

Re: The trouble with symbolic links

#62

Post by marcosdumay »

I really think that an "open the file as this user or group (also constrained to the current user's permissions)" option will solve the security problems better than the "open the file relative to this root" one. Or, failing that, an usable capability system (not SELinux).

I don't think just checking for symlinks really solves anything. It may make your bugs harder to exploit, what is always good, but people use symlinks, so you have to support them, so the bugs will stay there.

Re: The trouble with symbolic links

#63

Post by com2kid »

rob_c wrote: post #40
joosters wrote: post #14

Earlier quoted context omitted.

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.

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 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...

Re: The trouble with symbolic links

#64

Post by com2kid »

Beltalowda wrote: post #33
littlestymaar wrote: post #9

Earlier quoted context omitted.

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…

> 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…

> Bridges and buildings from the 1970s (and much older) are still working fine today.

With modern earthquake straps added, and I bet the locks got replaced a few times over, also the building likely had its insulation improved, better venting added, a sprinkler system, fire exits, and a wheelchair ramp put in at some point.

Are there a few quaint stone bridges from 1700 still in use? Sure, going over the neighborhood creek. But all the bridges around me have undergone serious upgrades or retrofitting over the decades.

Re: The trouble with symbolic links

#65

Post by seoaeu »

ploxiln wrote: post #36
3pt14159 wrote: post #30

Earlier quoted context omitted.

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…

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 pro…

> 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

Re: The trouble with symbolic links

#66

Post by 3pt14159 »

ploxiln wrote: post #36
3pt14159 wrote: post #30

Earlier quoted context omitted.

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…

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 pro…

I appreciate the reply, but after thinking about it I think it's more akin to someone having been sold a house only to be told eight years later that the seller of the house knew that if someone tied a shoelace to the front door and pulled on it, then the entire house would explode.

Could we consider it a broken doorknob Pierce?

Re: The trouble with symbolic links

#67

Post by DiggyJohnson »

js2 wrote: post #55
lxgr wrote: post #43

Earlier 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…

I tried to construct my argument to make it clear that I'm aware there are ways to solve the issues with hard links, but they have their own sets of trade-offs. For hard links, it's not only that they can cause loops. There are the other issues I outlined (linking across file systems, no single canonical representation of the file in the file system, finding all the links to the file, etc). There's no "just store a b…

Re: Symlink analysis: Well said.

> (As an aside, I've been really trying to stop using the word "just" lately as I've learned that things are rarely so simple to justify the word.)

Me too! I realized how it immediately frustrated me to hear it used about my domains. I’m constantly having to work to not seem as short/blunt/know-it-all as I feel. I think this word is a connotation trap, because when I use it feels inoffensive, but when I hear it seems blunt and dismissive and I’m quick to assume the person doesn’t understand or empathize with the complexities of the situation. That’s a long way of saying I really enjoyed your aside.

Re: The trouble with symbolic links

#68

Post by forrestthewoods »

Hard linking files isn’t useful in my experience because it requires every tool working with that file to never delete it and recreate it. However that’s what exactly many tools do. So the only way to reliably “share” a file is with a symlink. At least this is true for my workflows.

Re: The trouble with symbolic links

#69

Post by philsnow »

bhawks wrote: post #34

A posix filesystem by itself is not a defensible security perimeter. Symlinks introduce security problems but there are other sources as well. If you have a system where processes with different trust profiles share a common view of a file system you have to assume one can manipulate the filesystem state to subvert the other. Android has dealt with this via locking down and isolating apps to their own filesystems. Cr…

> The posix filesystem just doesn't have the abstractions/expressiveness one would need to build a robust security perimeter between untrusted apps.

This, absolutely, but I think it's even worse than that; in my mind the value prop of k8s is twofold: declarative configuration and isolation that forces apps to be able to interact over a very small boundary, the network overlay.

Re: The trouble with symbolic links

#70

Post by jandrese »

lxgr wrote: post #43
js2 wrote: post #38

I'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…

> 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…

> Couldn't this pretty easily be solved at the file system level? Just store a back pointer from a file to each of its names.

In theory yes, but no filesystem does this as far as I know.

Post reply on HN