Anyone making "Sandbox-Safe" Audio Units?

[Blue Cat Audio]

This inconsistency between APIs definitely freaks me out...

[aciddose]

What is wrong with using the existing c functions for this?

Code: Select all

int err;
FSRef ref;
OSStatus r = FSFindFolder(kUserDomain, kApplicationSupportFolderType, kCreateFolder, &ref);
assert(!r);
if (!r) {
	r = FSRefMakePath(&ref, (UInt8 *)path, 1024);
	assert(!r);
	strcat(path, "/");

	strcat(path, "vendor/");
	err = mkdir(path, 0777);
	chmod(path, 0777);
	assert(!err);

	strcat(path, "product/");
	err = mkdir(path, 0777);
	chmod(path, 0777);
	assert(!err);
}

I found that "mkdir" doesn't actually set the permissions on files which is why I follow it by a chmod...

Not sure if I've done something wrong, but it doesn't give any conditions where it shouldn't be working in the documentation

Oh I see, you're trying to get the actual user directory and not the sandbox directory...

In which case using pw->pw_dir in place of FSFindFolder/FSRefMakePath would do it?

The thing I don't like is manually inserting the "library/application support/" or any other path that isn't "owned" by the code. For example "vendor/product/" was just created and owned by the code but there is no way to know if "library/application support/" exists at all or what the permissions might be.

[Angus_FX]

That's ancient Carbon code.. indeed, could almost be System 6 code. Do those functions even exist on 64-bit Mac OS?

[aciddose]

I wouldn't have posted it if it didn't work.

[Blue Cat Audio]

It will probably not work for a long time: all these old Carbon FS functions have been deprecated in 10.8.

[aciddose]

Strange they would remove a c interface that works just fine and replace it with a garbage objc interface which is far more complex and difficult to use...

It's a shame there are no POSIX functions for this ("app data" directory), most *nix applications seem to just create a hidden directory in home, such as ~/.vendor/product/.

That seems a far safer bet given the need to hard-code "library/application support/". May as well just hard-code ".vendor/" instead and stick with 100% POSIX functions to do it.

Although I wonder if getpwuid(getuid()) works only because it "slipped through the cracks" and hasn't yet been overridden?

Does mkdir("~/.vendor") work? Going to try this...

Code: Select all

#include <wordexp.h>
wordexp_t exp_result;
int err = wordexp("~", &exp_result, 0);
path_to_home = exp_result.we_wordv[0];

I see comments that this function can (on OSX) fail sporadically though.

Also possible:

Code: Select all

char *path = getenv("HOME");

[Angus_FX]

I don't think it's a case of not-overriden.. the idea is that the userhome folders won't be read/writeable from inside a Sandboxed app, so while the function calls may give you a path, you won't be able to do anything with it.

[aciddose]

It wouldn't make much sense for any application to be disallowed from access to the home directory as the application would then not be capable of saving user files.

I doubt they're stupid enough to attempt something like that.

Apple is between a rock and a hard place here because either they allow home directory access so applications (and anything else, like virii) can work and read/write all user files, or they need to white-list various permissions on a per-application basis eliminating the whole "just works". (As if that were ever true anyway.)

I think manual white-listing by the user is great. I'd love this feature as I'd be able to protect my files and control access directly. I'm not a typical user.

[Angus_FX]

Not as simple as that.

Userhome and other directories can be accessed after user intent to access them has been communicated.

How do they determine user intent? Via their OS file dialogs. So if you use the system dialogs, you can get back a security scope that lets you write in that location. Use a custom file browser or custom file dialog? Sorry, you're now officially a second class citizen.

The objective here is to distinguish user-initiated filesystem actions from program-initiated ones. There's a security-scoped-bookmark scheme so you can persist the user's consent to read/write a specific location.

Oh, and the bookmark scheme is application-scoped. So if you're a plug-in, and you get loaded in a different host, you can't access any of your previous security bookmarks & you have to ask the user again.

The thinking behind it is roughly as follows:-
Previously, system data was held to be important (to be protected from inadvertent corruption by user activities or user programs), and user data was the user's responsibility. Nowadays, user data is considered to be a target for hackers. So the sandbox is there to protect people who run malware from having their accounts spreadsheets surreptitiously uploaded to some russian FTP site while their back is turned.

[aciddose]

What do you mean not as simple as that? As what?

You've just described user white-listing, although apple may have implemented it using file dialogs or whatever else it is still the same thing. It's a less direct and less powerful way (the user has less control and doesn't need to know what is going on 'behind the scenes') to manually white-list.

Popping up those dialogs is the consequence that can not be avoided. The user must manually white-list permissions.

This is why "just works" just won't work anymore. A plugin won't be able to for example automatically save and reload content, a dialog with manual user interaction will need to be involved.

No "automatic search for sample/preset libs" will be possible, they'll have to be manually selected by the user.

At least the first time.

I really don't mind this, I think it's great.

[audiospillage]

Not as simple as that.

Userhome and other directories can be accessed after user intent to access them has been communicated.

How do they determine user intent? Via their OS file dialogs. So if you use the system dialogs, you can get back a security scope that lets you write in that location. Use a custom file browser or custom file dialog? Sorry, you're now officially a second class citizen.

Our only sandboxed plugin so far is running fine in GB, Logic X and AULab. We are able to load presets from a custom drop down menu thing immediately after launch which completely bypasses any standard file dialogs. I was expecting that to fail:

/Library/Audio/Plug-Ins/Presets/AudioSpillage/DrumSpillageKits/Folder/

Has the above path been pre-flighted or is exempt from sandbox rules for some reason?

[aciddose]

Since the host has accessed library/plugins already it's likely white-listed by the time you access it.

Only question is whether sub-directories inherit permissions.

(Or, what I mean is whether the application is granted permissions for a whole node of the filesystem when it is white-listed for access to the parent directory.)

[audiospillage]

Since the host has accessed library/plugins already it's likely white-listed by the time you access it.

Only question is whether sub-directories inherit permissions.

(Or, what I mean is whether the application is granted permissions for a whole node of the filesystem when it is white-listed for access to the parent directory.)

Seems to be that way. And that concludes my sandbox drama. Although, I have to say, the per-host preferences file situation is sub-optimal. I'm not sure what can be done about that though.

[aciddose]

You would I suppose be forced to pop up a file dialog asking the user to select the "global preferences file" for loading/saving to get white-listed for access to it.

I have no idea how this "bookmarking" stuff works though so can't say whether that would only need to happen once, twice (for read and write) or each time?

[hibrasil]

does anyone know how you reset the security settings of garageband/logic X. I previously clicked "lower security settings" but would now like to try it as it was

cheers

oli