[0x0]

It's always good to see open source projects published, especially for tricky and often under-documented stuff like file system kexts.

Not to derail from this fine post, but I wanted to give a shoutout to FUSE for macOS (previously known as OSXFUSE). As an outsider from the project - merely a happy user - it seems to be a well maintained FUSE implementation for macOS, with signed kexts available. https://osxfuse.github.io/

[azinman2]

According to Dropbox it has performance & security risks: https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...

[sweettea]

According to Dropbox, it has performance implications and is complicated thereby introducing a large attack surface. For some reason, they believe their own kernel module is less complicated and easier to reason about than FUSE, despite having more in-kernel code and not being open source; I would venture to say their words about security are more about control of the attack surface rather than any actual implications about the quality of the FUSE code.

[Longhanks]

According to Dropbox it is okay to circumvent security mechanisms of the operating system (https://news.ycombinator.com/item?id=12463338) unless the media discovers your shady way of tricking the user into granting you full system access.

Their lost a lot of their credibility in my opinion.

[jjtheblunt]

why are there kexts in file system user space extensions? in OSX multiple driver types can exist entirely in user space, with no kext. [ former Apple engineer here ]

[0x0]

Are you saying you can write a 100% user-space "driver" that allows for `mount`ing into the regular file system? How does that work? Can a non-root user supply the code running to serve /some/path that is visible for any process on the system, even root?