3 ms·

Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn

by duped 3y ago

Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn't provide an API for this natively.

skissane 3y ago
> fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understand why Apple won’t. Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?
- nine_k 3y ago
  > why don't they It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces. Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a specialist OS completely controlled by Apple, with a few companies like Adobe and Ableton licensing access to its internals.
  - skissane 3y ago
    Apple used to be a lot more developer-friendly company. It is part of what got them where they are now - the fact that so many developers use Macs, which in turn encourages business software vendors to support Macs Stuff like this is of little interest to ordinary users (at least not directly), but appeals to developers By de-emphasising the developer is experience, they are undermining one of the factors that got them to where they are today
  - samatman 3y ago
    I've been using OSX since 2003, and developing on it for more than ten years. At no point have I seen anything that it's reasonable to call "tightening macOS", let alone the absurd claim of complete control except for an inner circle of elite companies. The closest thing would be adding the attestation system, so that unsigned binaries have to be explicitly given permission to run... once. That's a security feature which trades a bit of convenience for a lot of protection, especially for the average user. I have no problem with that sort of thing. I see this sort of sentiment very frequently from non-users of the operating system, but never from those of us who actually use it. Go figure.
- duped 3y ago
  > The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. If no one can call it it's not an API, it's an implementation detail. And I don't even think its exposed by headers, just alluded to by people who claim APFS is implemented in user space. > I was wondering what issues you were talking about, and then I found this Worse than this, it's possible to DoS a Mac with an NFS server just by refusing to reply to a request. That's unacceptable for a user space file system (although FUSE is only kinda better, in that it can force processes that read from the FS into uninterruptable sleep that prevents them from being killed). > Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not? Because Apple doesn't give a fuck about developers. Every developer will eventually learn this, but for those that haven't - Apple doesn't want you writing software for their platform, unless you're an Apple employee and on an Apple team paid to do it. It's why their docs suck, it's why to learn anything you need to watch ADC videos instead of read manpages, and it's why all the cool stuff is behind protected entitlements that you can't get or will be limited in using.
  - skissane 3y ago
    > Worse than this, it's possible to DoS a Mac with an NFS server just by refusing to reply to a request. I wonder if their SMB/CIFS client implementation has these kinds of issues? It probably gets used more heavily > And I don't even think its exposed by headers Apple (accidentally?) released some of the private headers for this feature in one of their open source releases: https://github.com/apple-oss-distributions/msdosfs/blob/rel/msdosfs-435/LiveFilesTester/UserVFS.h https://github.com/apple-oss-distributions/msdosfs/blob/rel/...
    - duped 3y ago
      Maybe? It's kind of hard to tell. It's not exactly easy to write any of these servers from scratch to find out. But I wouldn't be surprised - they want app developers to be using the file provider extension API, which is unsuitable for everyone who isn't making a Dropbox clone. That link is very interesting. It doesn't smell like any other Apple API as they're exposing a vtable with good documentation comments. It would be interesting to hack with this with SIP disabled to see how it works. I'm especially curious about how mount/unmount work and how the plugin registers itself with the OS, or what application is the client/host.

by duped 3y ago

Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn't provide an API for this natively.

skissane 3y ago

> fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understand why Apple won’t. Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?

nine_k 3y ago
> why don't they It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces. Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a specialist OS completely controlled by Apple, with a few companies like Adobe and Ableton licensing access to its internals.
- skissane 3y ago
  Apple used to be a lot more developer-friendly company. It is part of what got them where they are now - the fact that so many developers use Macs, which in turn encourages business software vendors to support Macs Stuff like this is of little interest to ordinary users (at least not directly), but appeals to developers By de-emphasising the developer is experience, they are undermining one of the factors that got them to where they are today
- samatman 3y ago
  I've been using OSX since 2003, and developing on it for more than ten years. At no point have I seen anything that it's reasonable to call "tightening macOS", let alone the absurd claim of complete control except for an inner circle of elite companies. The closest thing would be adding the attestation system, so that unsigned binaries have to be explicitly given permission to run... once. That's a security feature which trades a bit of convenience for a lot of protection, especially for the average user. I have no problem with that sort of thing. I see this sort of sentiment very frequently from non-users of the operating system, but never from those of us who actually use it. Go figure.
duped 3y ago
> The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. If no one can call it it's not an API, it's an implementation detail. And I don't even think its exposed by headers, just alluded to by people who claim APFS is implemented in user space. > I was wondering what issues you were talking about, and then I found this Worse than this, it's possible to DoS a Mac with an NFS server just by refusing to reply to a request. That's unacceptable for a user space file system (although FUSE is only kinda better, in that it can force processes that read from the FS into uninterruptable sleep that prevents them from being killed). > Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not? Because Apple doesn't give a fuck about developers. Every developer will eventually learn this, but for those that haven't - Apple doesn't want you writing software for their platform, unless you're an Apple employee and on an Apple team paid to do it. It's why their docs suck, it's why to learn anything you need to watch ADC videos instead of read manpages, and it's why all the cool stuff is behind protected entitlements that you can't get or will be limited in using.
- skissane 3y ago
  > Worse than this, it's possible to DoS a Mac with an NFS server just by refusing to reply to a request. I wonder if their SMB/CIFS client implementation has these kinds of issues? It probably gets used more heavily > And I don't even think its exposed by headers Apple (accidentally?) released some of the private headers for this feature in one of their open source releases: https://github.com/apple-oss-distributions/msdosfs/blob/rel/msdosfs-435/LiveFilesTester/UserVFS.h https://github.com/apple-oss-distributions/msdosfs/blob/rel/...
  - duped 3y ago
    Maybe? It's kind of hard to tell. It's not exactly easy to write any of these servers from scratch to find out. But I wouldn't be surprised - they want app developers to be using the file provider extension API, which is unsuitable for everyone who isn't making a Dropbox clone. That link is very interesting. It doesn't smell like any other Apple API as they're exposing a vtable with good documentation comments. It would be interesting to hack with this with SIP disabled to see how it works. I'm especially curious about how mount/unmount work and how the plugin registers itself with the OS, or what application is the client/host.