The long road to a fix for CVE-2021-20316

The long road to a fix for CVE-2021-20316

Posted Feb 23, 2022 12:11 UTC (Wed) by anton (subscriber, #25547)
In reply to: The long road to a fix for CVE-2021-20316 by nybble41
Parent article: 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

---

to post comments