3 ms·

> /Applications/SomeApp.app/users/taftster/user.specific.data This doesn't work well for a few reasons: - The Unix permission model makes it difficult to set

by comex 7y ago

> /Applications/SomeApp.app/users/taftster/user.specific.data This doesn't work well for a few reasons: - The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app. - Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image. - If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk. - It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature. - If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two. - If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.) > And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. Do you? - What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle. - What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data. - Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.

taftster 7y ago
All these are fair and good points. But all of these are still workable problems that should be very much in the capable hands and constraints of the operating system and "app bundle runner" (call it) to deal with. Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters. Applications should be treated as hostile, just like a user is treated in a multi-user system. I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out. I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem. In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download. It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.
- comex 7y ago
  For the record, sandboxed macOS apps do exist (as someone mentioned upthread) and have a design somewhat similar to what you're describing, but uglier for the sake of backwards compatibility. For each app you have a directory like /Users/foo/Library/Containers/com.some.bundleid/Data, which is an entire virtualized home directory, containing not just a Library subdirectory but also Desktop, Documents, Downloads, etc. The latter directories shouldn't actually be used, but they're there in case some legacy code tries to access them. When an app presents an open or save dialog, the dialog is out-of-process and unsandboxed, so the user can pick a file from their real home directory or anywhere else; once they do so, the app is automatically granted the ability to access that particular file.

by comex 7y ago

taftster 7y ago

All these are fair and good points. But all of these are still workable problems that should be very much in the capable hands and constraints of the operating system and "app bundle runner" (call it) to deal with. Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters. Applications should be treated as hostile, just like a user is treated in a multi-user system. I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out. I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem. In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download. It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.

comex 7y ago
For the record, sandboxed macOS apps do exist (as someone mentioned upthread) and have a design somewhat similar to what you're describing, but uglier for the sake of backwards compatibility. For each app you have a directory like /Users/foo/Library/Containers/com.some.bundleid/Data, which is an entire virtualized home directory, containing not just a Library subdirectory but also Desktop, Documents, Downloads, etc. The latter directories shouldn't actually be used, but they're there in case some legacy code tries to access them. When an app presents an open or save dialog, the dialog is out-of-process and unsandboxed, so the user can pick a file from their real home directory or anywhere else; once they do so, the app is automatically granted the ability to access that particular file.