pleroma.debian.social

STOP DOING HARDLINKS

INODES WERE NOT MEANT TO EXIST IN MULTIPLE DIRECTORIES

YEARS OF FILES yet NO REAL-WORLD USE FOUND for being in more than one directory

Wanted to reference files from more than one directory anyway? We had a tool for that: it was called "SYMLINKS"

"Yes please give me FIFTEEN paths that this file resolves to" - Statements dreamed up by the utterly Deranged

"Hello I would like different permissions on this file based on path" They have played us for absolute fools

@mjg59 you’re ruining my backups.

@cate Maybe our tooling should be better

@mjg59 It had somehow never occurred to me that hardlinks have multiple completely independent permissions. That is hilarious and I will now be pondering silly ways to abuse that knowledge. That applies to SELinux type and context labelling too, doesn’t it? Oh dear.

@TonyYarusso SELinux is actually fine because the context is applied to the inode

@mjg59 funnily enough I am beginning to feel the same way about symlinks.

@wjt Oh no

@TonyYarusso @mjg59 Hardlinks don't have independent permissions. Permission bits are part of inodes, not part of directory entries.

The directories that contain entries pointing to those inodes can have different permissions, though, and the x-bit for those directories matters.

@neverpanic @TonyYarusso depends on how we define "permissions" - apparmor contexts are applied based on path

@mjg59 Huh, good to know. And the fact that the two are *different* will now bother me, so THANKS for that. :P

@TonyYarusso @mjg59 I’m sorry you all, but security contexts (including extended attributes) are all stored in the inode. So you cannot have different security settings on hard links as you seem to be implying.

@mjg59 in my mind this rant is hardlinked to every "stop doing symlinks" rant I've ever read

@hal_pomeranz @TonyYarusso Apparmor imposes policy based on path, not inode contents. You can absolutely have different policy depending on how you address the file.

@mjg59 @TonyYarusso Which is actually one of the primary (but few) “cons” for AppArmor vs SELinux.

@mjg59 @numist The tiny angry little hobby horse I slowly carve for myself is that POSIX has gotta go. Slowly. Into the night. With respect and thanks. But, you know, let’s get a reset.

@Gte @mjg59 @numist Writing a file system really throws in your face how broken it is.

@shac @Gte @mjg59 IT'S SO BAD

@numist @shac @Gte @mjg59 yeah what you really want is more the moral equivalent of a CoW mapping of a file, IOW something where you can link-and-snapshot cheaply. hardlinks suck otherwise.

@madcoder @numist @Gte @mjg59 I want a lot of things. A native key-value store that can be serialized. Searchable file attributes that don’t require crawling a directory tree and poking every inode. A sane way to share files between untrusted processes. Transactional IO without sync(), including metadata ops. Copying thousands of files at disk io speed. …
POSIX semantics are very dumb. I’d like something better.

@shac @numist @Gte @mjg59 “Better than POSIX semantics” now that's a high bar

@mjg59 I remember having a problem with symlinks not being resolved and just being opened as raw link files, but that was on cygwin and it's just stuck with me ever since

every once in a while, to this day, i symlink something and get all surprised that it works correctly instead of just being a text file with the target path

but back on cygwin, it was so bad i actually had a valid use case for hardlinking directories

@minervous https://stackoverflow.com/questions/23086038/what-mechanism-is-used-by-msys-cygwin-to-emulate-unix-domain-sockets

@hal_pomeranz @TonyYarusso @mjg59

"you cannot have different security settings on hard links"

Don't lots of things consider the security settings of every directory between / and the inode of interest? In which case you can have multiple...

Doesn't ssh complain if your home directory (containing your .ssh directory containing your secret keys) is writeable by the group or others?

@stuartyeates @TonyYarusso @mjg59 But now you are talking about multiple objects. Go back and read the thread. My point was you cannot have multiple security settings on a single inode, even if there are multiple paths to that inode due to hard links.