[HN Gopher] Posix hardlink heartache
___________________________________________________________________
Posix hardlink heartache
Author : cristoperb
Score : 82 points
Date : 2021-07-06 15:21 UTC (7 hours ago)
(HTM) web link (michael.orlitzky.com)
(TXT) w3m dump (michael.orlitzky.com)
| bloak wrote:
| So, which systems allow hard links to directories?
| dfox wrote:
| There is a difference between "allows hardlinks to directories
| to exists" and "allows user to straighforwardly create them".
| As for existence most unix filesystems have exactly zero issue
| with that, while on systems that allow you to link(2) to
| directory you have to be root to do that.
|
| Hardlinks to directories not only break bunch of userspace
| expectations, but more importantly create a structure that
| cannot be unlink(2)ed (unlink(2) does not work on directories
| and rmdir(2) works only for directories with st_nlink==2). So
| even on systems that allow creation of that it is restricted to
| root.
| themadsens wrote:
| Every (posix) directory has "." and ".." which are both
| hardlinks to a directory ..
| eqvinox wrote:
| ~None. It breaks too many assumptions when you can have the
| file system tree loop around on itself.~
|
| Edit: WTF, apparently it's a core Apple Time Capsule feature.
| Okay. Cool. Never touching that.
|
| Edit2: https://arstechnica.com/gadgets/2011/07/mac-
| os-x-10-7/12/ claims that hard links are actually hidden
| files(?) on HFS+:
|
| > _One particularly scary example is the implementation of hard
| links on HFS+. To keep track of hard links, HFS+ creates a
| separate file for each hard link inside a hidden directory at
| the root level of the volume. Hidden directories are kind of
| creepy to begin with, but the real scare comes when you
| remember that Time Machine is implemented using hard links to
| avoid unnecessary data duplication._
| dfox wrote:
| HFS+ is still only somewhat extended HFS and the filesystem
| itself does not support hardlinks to anything. The support
| for hardlinks is simulated in upper layers which while being
| questionable design on its own somewhat alleviates the usual
| problems with directory hardlinks.
| masklinn wrote:
| macOS.
|
| IIRC ln(1) can't create directory hardlinks, but link(2) allows
| it (on HFS+, directory hardlinks were not ported over to APFS).
|
| Directory hardlink support was originally added for time
| machine.
| [deleted]
| LeoPanthera wrote:
| macOS allows it as of 10.5, but it is not exposed to the user.
| The "Time Machine" backup tool built into macOS relies on it.
|
| AT&T UNIX System V allowed it for the root user only.
| masklinn wrote:
| > macOS allows it as of 10.5, but it is not exposed to the
| user.
|
| Depends what you mean by "not exposed to the user": while
| ln(1) can't create directory hardlinks it works fine via
| link(2) (on HFS+), with the limitation that hardlinked
| directories can't be siblings.
|
| And of course directory hardlinks are fucking terrifying
| because `unlink(1)` will not work, and `rm(1)` will
| recursively remove directory contents, so you need to go
| through `unlink(2)` in C.
| bodhiandphysics wrote:
| This seems to me to be a bit of throwing out the baby with the
| bathwater... the problem isn't links but rather setuid programs
| changing file permissions in user writable directories!
| tryauuum wrote:
| good news is that fs.protected_hardlinks is enabled on debian and
| ubuntu
| tedunangst wrote:
| The usual defense is to keep user writable spaces on separate
| mount points, where in theory they may be able to link with each
| others' files, but not anything important. And then be mindful
| about whatever dumb script you run that mucks with permissions.
| viraptor wrote:
| "others' files, but not anything important" reminded me of
| https://xkcd.com/1200/ - user files are pretty much the only
| important thing in many scenarios.
| tedunangst wrote:
| Users have a trivial defense: set permissions to prevent
| others from seeing the files. System files tend to live in
| world readable directories.
| eqvinox wrote:
| I don't see how the security issues described in this article are
| really tied to hardlinks. If root is doing chmod/chown in a
| directory that is writable by untrusted users, the same untrusted
| users can also just remove or rename files. Is there any example
| that demonstrates an exploit specifically relying on hardlinks?
| dfox wrote:
| You can link a file that is outside of that directory and thus
| get write access to that file. (Canonical example is linking
| /etc/passwd somewhere where you expect root to do chown -R you
| .)
| cristoperb wrote:
| The author links to one example at the top of the article
| ("CVE-2017-18188: opentmpfiles root privilege escalation via
| recursive chown"):
| http://michael.orlitzky.com/cves/cve-2017-18188.xhtml
|
| Apparently a user can create a hardlink to a sensitive root-
| owned file (like /etc/shadow) in a user-writable directory
| where they know a privileged process (in this case tmpfiles.d)
| will come along and chown it to the user, after which that user
| will own the sensitive file too.
| Negitivefrags wrote:
| Couldn't they introduce the same security feature mentioned
| for symlinks?
|
| As in, make it so by default you can't create a hard link to
| a file you don't already have write access to?
| cristoperb wrote:
| Linux does (since version 3.6) have the ability to prevent
| users from creating hardlinks to files they don't own. (See
| man 5 proc under "/proc/sys/fs/protected_hardlinks".) I
| think FreeBSD has a similar sysctl option.
|
| The linked article does mention it but warns "If you're not
| using systemd, the vanilla Linux kernel does not enable
| these protections by default".
| tyingq wrote:
| >Couldn't they introduce the same security feature
| mentioned for symlinks?
|
| _" The tmpfiles.d specification for the Z type more or
| less implies some kind of recursive chown. The spec heads
| off one type of vulnerability by saying that symlinks
| should not be followed; however, hard links are still a
| problem"_
|
| https://github.com/OpenRC/opentmpfiles/issues/3
|
| >As in, make it so by default you can't create a hard link
| to a file you don't already have write access to?
|
| From the CVE: _" when the fs.protected_hardlinks sysctl is
| turned off"_
|
| A description of that: _" When set to "1" hardlinks cannot
| be created by users if they do not already own the source
| file, or do not have read/write access to it."_
| gunapologist99 wrote:
| From the linked article, "If you're not using systemd,
| the vanilla Linux kernel does not enable these
| protections by default"
|
| ... which just seems a bit discriminatory.
| tyingq wrote:
| Torvalds did weigh in on it. It's disabled by default
| because it apparently breaks some legacy stuff.
|
| https://github.com/torvalds/linux/commit/561ec64ae67ef25c
| ac8...
| jra_samba wrote:
| No so much harlinks, but symlinks are a blight on the POSIX
| filesystem design. They have caused endless pain and suffering
| and so many, many CVE's. They need to be eliminated.
| tryauuum wrote:
| why can't they both be bad things? :)
|
| I once googled if there is a mount option to disable symlink
| creation, unfortunately there is no.
| matheusmoreira wrote:
| They are so useful though.
| deckard1 wrote:
| I'd be curious to know what use case people have today for
| hardlinks, ever since symlinks became a thing.
|
| I've been using Linux for more than 20 years and the only case
| I've found is for rsync incremental backups (--link-dest option),
| which is great for doing backups to an external USB hard drive
| and saving space. But that's rather niche.
| singron wrote:
| Reflinks on CoW filesystems are also good for that (along with
| native features like snapshotting, which are sort of a reflinks
| of a directory).
| anyfoo wrote:
| git uses them for local clones.
| gunapologist99 wrote:
| not so niche. That's a really terrific use for them. Hardlinks
| are hampered compared to symlinks because they can't be used
| for directories (which seems just a really silly limitation).
| It would be awesome to be able to roll up and mirror entire
| directory trees.
| caf wrote:
| _(which seems just a really silly limitation)_
|
| It's the most straightforward way to ensure the directory
| structure remains a directed acyclic graph.
| viraptor wrote:
| With newer systems this can be often handled at the os level.
| Both xfs and btrfs support copy-on-write, so you can have the
| same effect just by doing "cp --reflink".
| gunapologist99 wrote:
| Sure, that will do a CoW copy, but it's not actually the
| same effect at all, is it? In other words, writing to the
| copy will not propagate the writes to the original. (or am
| I wrong on that)
|
| Besides, won't this walk and copy the entire directory
| _subtree_? (i.e., CoW only applied to the files themselves,
| not just directory entries.)
|
| I'm saying I'd like to just have a hard link to the
| directory itself; if the directory is effectively a list of
| inode pointers, I just want to add another pointer to
| _that_ list of pointers. Then, if I create or modify a new
| file in some deep nested directory in either copy, it will
| be instantly available in both or more locations without
| any metadata changes on disk to more than one copy of the
| metadata itself. This would be interesting for certain use
| cases.
| mjevans wrote:
| Sometimes multiple writable entries for a single object are
| desirable.
|
| As an advanced feature there's plenty of room for abuse and
| footgun problems, but it's still occasionally, maybe even
| rarely, the correct tool for the job.
| lifeisstillgood wrote:
| I am trying to work out the level of (useless?/unnecessary?)
| churn in the world of startups / digital transformation / world.
|
| So, yes the Internet is _great_ - it connects what 5 billion
| adults now, and allows faster finding of the things you want etc.
| But there is soooo much ... of this stuff. I am guessing that
| "Digital marketing for the Rental market" means you have a house
| to let, and you want to list it with these people and their five
| competitors because you might miss out because who knows where
| one's audience really looks.
|
| Now we could talk about disaggregation of AiBnB as a positive
| thing, but really - no, lets not.
|
| What we can talk about is there is a bare minimum of cost /
| effort we can imagine here. Call it a Craigslist for the whole
| internet. Want to sell something - just find the right RDF tuple
| and list it. A search engine can find it and anyone searching for
| "house to rent in London" or "new pair trainers" will have a
| complete JSON list to walk through - sortable by price, location,
| availability etc etc.
|
| Now this is not something I think _should_ exist, but if it _did_
| it would still have a _cost_ to operate. But we could measure the
| unnecessary _churn_ by comparing the actual cost (in people,
| dollars, time etc) of things like RentPath to this bare minimum.
|
| I expect there are Economics PhDs on this, but it struck me as
| interesting.
| wmanley wrote:
| See also: Ghosts of Unix past, part 4: High-maintenance designs:
| https://lwn.net/Articles/416494/
|
| > While hard links are certainly a lesser evil than setuid, and
| there is little motivation to rid ourselves of them, they do
| serve to illustrate how a seemingly clever and useful design can
| have a range of side effects which can weigh heavily against the
| value that the design tries to bring.
| [deleted]
___________________________________________________________________
(page generated 2021-07-06 23:01 UTC)