[andrewfong]

Isn't this the basic idea behind the sandbox in OS X?

I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address.

First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broader access.

Second, as a corollary of the first, that means you're going to have a lot of apps that legitimately need to ask users to approve broader access. And as the number of apps asking for approval goes up, the more likely users are to simply ignore the warning and approve all. This is especially problematic since we can assume the average user is a good judge of which apps need which access.

Edit: One way of reducing user acceptance fatigue might to introduce greater granularity into the requested permissions and then tier the permissions requested -- e.g. commonly asked vs. uncommon. E.g. an app may legitimately need permission to write to any file in your home directory, but it's highly unlikely they'll need permission to write to more than X number of files per second. Or at least they shouldn't be able to do so without the OS throwing up lots of warnings outside of the app.

[ejdyksen]

Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1].

For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed container.

[1] https://developer.apple.com/library/mac/documentation/Securi...

[quotemstr]

Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.

[chopin]

But these are applications for knowledgeable users I think which is not the type of users the GGP is talking about. For these it might be ok to ask for permission. Or to grant it automatically if you are root or sudo'ed. And many use cases could get around with allowing silently to write if the file has been previously been opened by the same application.

[quotemstr]

I will not use a system that pops up some kind of UAC-like approval dialog for every call Emacs makes to open(2).

[wlesieutre]

The OS X sandbox doesn't work that way. If you do "Open" and pick the root of your hard drive one time, the application gets and keeps access to the entire drive.

Disk scanning programs like DaisyDisk from the app store have to make you do this before they can get any information about disk usage.

[ejdyksen]

Well, of course, sandboxing is opt-in, and there are still lots of programs out there that don't use them.

I'm not sure Emacs or vim, as an example, would ever be able to be sandboxed from the filesystem.

[wtallis]

Aquamacs seems to use the system dialogs with no trouble.

[quotemstr]

Sure, File->Open invokes the system dialog. Not C-x C-f. Not automatic filename history, or tags table traversal, or perusal of the M-x grep results buffer, and so on. Emacs is a generic runtime environment and needs generic file access.

[gizmo686]

It helps if you assume good faith of the application developer. Part of developing an application should be defining what permissions you need at install time. This won't help against legitimate malice, but it would defend against this type of mistake, and (if it is configured such that the app cannot change its own permissions) will also mitigate any exploit of the app.

[Karunamon]

Is it really a net improvement? There are a number of developers out there that have pulled out of the app store (off the top of my head, Atlassian for SourceTree, and Panic for Transmit) because the sandbox restrictions would force them to remove functionality from their applications.

As far as Apple's implementation goes, sandboxes are for kids, not adults that need to get work done.

[dietrichepp]

SourceTree and Transmit need to stomp all over directories to get things done. Yes, it's useful. But it's not common for applications to need that kind of access. The sandbox seems to work fine for the other 99% of applications. I think Apple even uses the sandbox heavily for their own apps, check ~/Library/Containers next time you use an OS X system.

The only complaint here is about the app store, sandboxing is wonderful.

[pjc50]

Steam is another category of application which wants to write to directories used by other applications...

[gurkendoktor]

Why? In my Windows VM, all Steam data lives in C:\Program Files\Steam. (Plus start menu entries etc.)

[pjc50]

Steam manages game installation and updates; those games are themselves separate applications. That's what I was referring to.

[Chris_Newton]

There seem to be several reasonable ways to address this kind of situation without requiring universal access.

One would be analogous to an ACL arrangement rather than simple ownership. Steam applications could be installed with Steam also having permission to access their resources.

A second possibility would be to have the operating system provide dedicated services for installing and maintaining software. We’re already heading in that direction on some platforms anyway, and it would be useful generally given the kind of security model I suggested. Then software like installers/updaters or package managers can do their jobs in a tightly controlled way, without needing any general access or introducing the accompanying security risks.

[deafbybeheading]

Why not have Apple require apps to run usefully with just basic permissions? Anything beyond access to own files is optional. This could certainly be gamed, but scrupulous app authors could gain a ton of trust from playing ball.

[_jsn]

This is essentially already the case as Mac App Store apps must be sandboxed. This works fine for a lot of apps, but has presented issues for many prominent developers. (e.g. Panic had a fairly difficult time adapting Coda to the sandbox, if I recall correctly.)