The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
Posted Feb 15, 2022 17:44 UTC (Tue) by nybble41 (subscriber, #55106)In reply to: The long road to a fix for CVE-2021-20316 by Wol
Parent article: The long road to a fix for CVE-2021-20316
* You can symlink across filesystems, but hard links only work within filesystems.
* If a file is deleted and replaced (i.e. the ubiquitous "atomic rename" pattern) this breaks hard links, but not symlinks.
* Symlinks can point to directories, while hard links to directories are either disallowed altogether or heavily restricted.
* Symlinks interact better with filesystem quotas. If you can create a hard link to a file owned by another user in a location they can't access, and the original path is later deleted, then you can cause that part of their quota to be permanently inaccessible to them. (Alternatively, the system can disallow hard links to other user's files—in which case the advantage of symlinks is not having this restriction.)
* You can read a symlink to determine where it goes, but with hard links you only have an inode number.
* Directory entries accessed through symlinks have canonical paths, but hard-linked inodes have multiple, equally authoritative, paths.
> Coming from OSs that didn't have symlinks, I don't use them.
Which OS do you use that doesn't have symlinks? Not Linux, or MacOS, or Windows… though symlinks in Windows are a bit different, it does have them. You create them with the "mklink" command. They aren't strictly limited to administrator accounts either; that's just a default setting. The biggest difference is that Windows distinguishes between symlinks to files and symlinks to directories. It also has "junction points" which work much like symlinks (but only for directories). Also let's not forget "shortcuts" (*.lnk files), which are basically symlinks implemented somewhat inconsistently at a layer above the kernel. These have been around since Windows ran under DOS.
Posted Feb 15, 2022 19:24 UTC (Tue)
by jra (subscriber, #55261)
[Link] (2 responses)
After enough years, I'm convinced they were a foundational mistake in POSIX. We need to move past them and stop this mistake from being repeated. More in my SambaXP talk :-).
Posted Feb 15, 2022 20:13 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Feb 16, 2022 18:55 UTC (Wed)
by jra (subscriber, #55261)
[Link]
They actually change the view of the filesystem hierarchy in a way that symlinks don't. Symlinks are a point attack that can modify a specific path quickly and easily to anywhere on the filesystem if allowed or exposed over a network filesystem. IMHO they are much more dangerous.
Posted Feb 15, 2022 19:45 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (3 responses)
DID I use ... they pre-date linux, MacOS and Windows ...
A Multics-derivative called Pr1mos, various DOSes (I don't think I used CP/M ...) (and I don't mean MS-DOS and derivatives ...)
There used to be a world with many different OSes, not just the three behemoths we have now.
Cheers,
Posted Feb 16, 2022 15:06 UTC (Wed)
by foom (subscriber, #14868)
[Link] (2 responses)
This allows them to be less fragile -- they store multiple ways of finding the original file, so it can still be used even in case the target has been moved or renamed. They can also do things like display a gui prompt to ask the user to insert the appropriate floppy disk which contains the target file, or automatically mount the proper remote volume.
However, the downside is that they are not functional for command-line/cross platform programs, which don't use alias-aware file access apis.
Posted Feb 17, 2022 12:52 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
But classic MacOS had no support for command-line apps which solved that problem.
Posted Feb 19, 2022 21:56 UTC (Sat)
by foom (subscriber, #14868)
[Link]
(Of course modern macos does have both command line POSIX apps and aliases)
Posted Feb 16, 2022 14:22 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Some programs still break symlinks because they operate on the pathname, not the result of following the symlink (basically, they replace the symlink instead of replacing the destination file).
Posted Feb 17, 2022 14:43 UTC (Thu)
by Karellen (subscriber, #67644)
[Link]
Posted Feb 23, 2022 12:11 UTC (Wed)
by anton (subscriber, #25547)
[Link] (1 responses)
Posted Feb 23, 2022 19:37 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link]
Yes, but you can create a hardlink to a file you don't own in a location which the owner of the hardlinked inode can't access. If they later lose their own path to the inode (by unlinking it, for example) then the inode continues to exist, because of the hardlink, and thus continues to count against their quota, but they have no way to remove it.
The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
Wol
The long road to a fix for CVE-2021-20316
> However, the downside is that they are not functional for command-line/cross platform programs, which don't use alias-aware file access apis.
The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
I think the parent commenter was referring to the case where you have a symlink somewhere pointing to /foo/bar, and /foo/bar is replaced through its canonical path, rather than through the symlink. In that case, the symlink (wherever it is) remains pointing at the new /foo/bar
The long road to a fix for CVE-2021-20316
The long road to a fix for CVE-2021-20316
* Symlinks interact better with filesystem quotas. If you can create a hard link to a file owned by another user in a location they can't access, and the original path is later deleted, then you can cause that part of their quota to be permanently inaccessible to them. (Alternatively, the system can disallow hard links to other user's files—in which case the advantage of symlinks is not having this restriction.)
Given that ownership (and pretty much all other metadata) is stored with the inode, and a hard link is just another reference to the same inode, it's impossible to create a hard link with different ownership (or other metadata) than the original. On some file systems you can create a reflink (new inode, shared data); I don't know how these file systems implement the quota in this case, but IMO the way to handle this is to blame the cost of the file in full on all users (i.e., as in a regular copy).
[/tmp:128248] ls -l foo
-rw-r--r-- 1 root root 4 Feb 23 12:56 foo
[/tmp:128249] ln foo bar
ln: failed to create hard link 'bar' => 'foo': Operation not permitted
[/tmp:128251] cp --reflink foo bar
[/tmp:128252] ls -l bar
-rw-r--r-- 1 anton users 4 Feb 23 12:57 bar
The long road to a fix for CVE-2021-20316