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

101–110 of 126 posts

Re: The trouble with symbolic links

#101

Post by inkyoto »

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?

It will not solve a problem that does not even exist in the first place, but will rather badly break the semantics of the UNIX file system precisely at the file system level.

> Just store a back pointer from a file to each of its names.

UNIX file systems do not have files in the conventional sense. They have disk block allocations referenced to by an inode and one or more directory entries pointing back to a specific block allocation via the associated inode. This makes hard links easily possible and very cheap. It is a one to many relationship (one block allocation to many directory entries), and turning it into a many to many relationship, with each directory entry pointing to every single possible permutation of other directory entries across the entire file system a nightmare in every imaginable way.

It is even possible to zero directory entries pointing to an inode (if you poke around with the file system debugger, you can manually delete the last remaining directory entry without releasing allocated blocks into the disk block pool but the next fsck run will reclaim them anyway).

Re: The trouble with symbolic links

#102

Post by School-Cotton »

kllrnohj wrote: post #37
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…

I don't think that's entirely true. There's plenty of major systems that have made fundamentally incompatible breaking changes in order to move things forward. Windows did that with Vista, Android did that with Linux (eg, app sandboxing per UID, heavily restricted filesystem access to shared directories), etc.. It's kinda mainly desktop/server Linux where there's this inability to move forward.

Android was for a type of device and userbase that had never run Linux, and so there were no pre-existing notions about what it should do, no pre-existing programs that needed to run, etc.

A better example would be Apple which makes breaking changes to both iOS and macOS absolutely all the time.

Re: The trouble with symbolic links

#103

Post by School-Cotton »

littlestymaar wrote: post #9
mongol wrote: post #7

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

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…

Does writing count as technology? The Chinese characters are thousands of years old.

Re: The trouble with symbolic links

#104

Post by XorNot »

GoblinSlayer wrote: post #84
XorNot wrote: post #54

Earlier quoted context omitted.

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

The difference is a symlink at least declares this explicitly. A hard link on the other hand looks and works like an independent file...but isn't one.

Re: The trouble with symbolic links

#106

Post by kazinator »

IshKebab wrote: post #93
waynesonfire wrote: post #74

Earlier quoted context omitted.

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.

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

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"

Re: The trouble with symbolic links

#107

Post by [deleted] »

joosters wrote: post #8
mongol wrote: post #7

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

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.

[deleted]

Re: The trouble with symbolic links

#108

Post by bartimus »

WhatIsDukkha wrote: post #98
bartimus wrote: post #97

I was copying a file today and thought: "Why is it duplicating the data? Why does it not just create a new second filename pointer in the filesystem?"

Take a look at the cp man page - https://www.man7.org/linux/man-pages/man1/cp.1.html Look for "reflink" and you get your wish :)

Very cool! :)

Re: The trouble with symbolic links

#109

Post by IshKebab »

kazinator wrote: post #106
IshKebab wrote: post #93

Earlier quoted context omitted.

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

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: "..…

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.

Re: The trouble with symbolic links

#110

Post by kllrnohj »

School-Cotton wrote: post #102
kllrnohj wrote: post #37

Earlier quoted context omitted.

I don't think that's entirely true. There's plenty of major systems that have made fundamentally incompatible breaking changes in order to move things forward. Windows did that with Vista, Android did that with Linux (eg, app sandboxing per UID, heavily restricted filesystem access to shared directories), etc.. It's kinda mainly desktop/server Linux where there's this inability to move forward.

Android was for a type of device and userbase that had never run Linux, and so there were no pre-existing notions about what it should do, no pre-existing programs that needed to run, etc. A better example would be Apple which makes breaking changes to both iOS and macOS absolutely all the time.

For the launch version sure but Android has made no shortage of breaking changes since then, like all the storage changes. Or selinux clamp down. Or permission changes. Or background restrictions. Or etc...
Post reply on HN