Elektrine lite

← Feed

@swick@hachyderm.io

Post #1628883

2026-04-23 20:48 UTC

Trying to answer a question no sane person ever had to ask: How Hard Is It, To Open a File? This one is about the great POSIX idea of a filesystem, and why you could not play your games and open chrome for a few days. https://blog.sebastianwick.net/posts/how-hard-is-it-to-open-a-file/

Replies (17)

  • @jimmac@mastodon.social 2026-04-23 20:58

    @swick Didn’t understand 80% of that, but thank you :)

    Open ##1887716

  • @berto@floss.social 2026-04-23 23:02

    @swick that was a really nice blog post, thank you!

    Open ##1887718

  • @federicomena@mstdn.mx 2026-04-23 23:10

    @swick ocaps ocaps *bangs table, stamps feet* OCAPS OCAPS

    Open ##1887719

  • @spyke@mastodon.online 2026-04-23 23:14

    @swick Would Glib address any of that?

    Open ##1887721

  • @jamesh@aus.social 2026-04-24 03:20

    @swick For securely using path based APIs like the old mount syscall, passing "/proc/self/fd/NNN" paths is an option. While they look like symlinks from user space, they're treated specially by the kernel and will resolve to whatever the file descriptor points to race free. I've used that to do bind mounts between possibly hostile locations after resolving the paths similar to how you describe.

    Open ##1887722

  • @pq@floss.social 2026-04-24 05:16

    @swick well written, and awesome work!

    Open ##1887724

  • @waldi@chaos.social 2026-04-24 07:06

    @swick "2a01:4f8:c012:2e79::" as listed in DNS for blog.sebastianwick.net does not answer to me on HTTPS.

    Open ##1887725

  • @saraislet@infosec.exchange 2026-04-24 07:50

    @swick That was a terrific explanation of a lot of subtle things, thank you!

    Open ##1887728

  • @JdeBP@mastodonapp.uk 2026-04-24 09:49

    @swick I've long thought that there's a hole that needs filling, that does what the original #Unix namei does but allows application mode code to supply everything necessary as (opaque) open descriptors: the root directory, the working directory, and the security credentials. Frustratingly, Unix openat(), Windows NT's NtCreateFile(), and #Hurd's dir_lookup() all come close but all miss a final piece of the puzzle in different ways. openat() misses, for example, a descriptor for the root directory and something like NT's process token handles for security processing. NT has odd ideas about current directories. This way, server processes could simply make use of the kernel's own already existing logic to handle not traversing '..' over a changed root, following symbolic links, and checking security using client credentials. There's so much reinvention of this wheel that would have been resolved decades ago if it had only been exposed as a system call. #filesystems

    Open ##1887729

  • @giggls@karlsruhe-social.de 2026-04-24 11:53

    @swick One former older colleague once told me that the big advantage when migrating from VMS to Unix was, that it got very easy to open a file. Have never been using VMS myself though.

    Open ##1887733

  • @pid_eins@mastodon.social 2026-04-24 11:56

    @swick great post! The sad part is that even after all those years chaseat() in systemd still gets relevant changes every few months, that non-trivially rearrange my PoV on file system interfacing. I.e. right now we are working on reinventing chaseat() around a new InodeRef structure that combines and fd *and* a path into one (together with some other fields) so that we don't lose the ability to write useful log messages (you really want a path for that) but can do the actual ops via fds...

    Open ##1887734

  • @zygoon@fosstodon.org 2026-04-24 12:46

    @swick Insightful post. Snapd has had a paranoid approach to fd security but even with that ww did commit a few CVEs over the years. I agree that starting with current kernel APIs would be far easier to do the right thing. The openat2 and the new mount system calls are way better if you can depend on them. Out of the missing set I wish kernel had an openat flag that makes atomic chown, and similar feature for mkdirat. Best regards!

    Open ##1887746

  • @jessica@gts.woollybear.xyz 2026-04-24 13:24

    @swick This was a very thought provoking blog post, particularly as I am currently developing an app that handles files. I think this problem should be mostly nonexistent in my app, as files are provided from other trusted applications, but I suppose it would be beneficial to protect against those trusted apps anyway just in case they get hacked. Therefore I will think about it as I am writing my code. Thanks!

    Open ##1887751

  • @swick as the world's biggest openat() propagandist (self-proclaimed) [1] i approve this message (super happy about the work, thanks!)

    Open ##1887753

  • @daandemeyer@mastodon.social 2026-04-25 06:39

    @swick I just landed a refresh to chaseat() in systemd so it takes separate root and directory file descriptors as part of the InodeRef prep work. The only annoying thing about that is you can't easily check if a directory file descriptor is a child of another directory file descriptor. You have to walk upwards to check which is just horribly slow.

    Open ##1887754

  • @addison@nothing-ever.works 2026-04-26 07:01

    @swick@hachyderm.io I propose to you the opposite question: how hard is it to not open a file? Magic links, special mounts, stale filesystems...

    Open ##1887756

  • @ju@chaos.social 2026-04-27 07:36

    @swick great write up and thank you for your work!

    Open ##1887757