Mac: Ensure that the kext blocks file I\O that that is not allowed when VFSForGit is unmounted

[wilbaker]

We used to have this on Mac, but it had to be removed in #191 as it was preventing:

• VFS4G from modifying the .git/hooks a as part of mounting
• gvfs repair from being able to fix up files in the .git folder

As the feature is re-enabled we'll need to consider how we can still support the scenarios above. Perhaps we can support a new xattr that VFS4G sets on folders letting the kext know that offline modifications are allowed? Or maybe there is some way that we can ACL/mark the VFS4G processes so that the kext knows that they should be allowed to make offline modifications?

[pmj]

Or maybe there is some way that we can ACL/mark the VFS4G processes so that the kext knows that they should be allowed to make offline modifications?

Can we have these processes, or at least a parent process of these processes register with the kext? From the kext's point of view, this is going to be the easiest method: any process wanting to modify offline roots needs to open a connection to the kext. We can either create a new IOUserClient subclass for this, or possibly roll it into the "provider" client subclass - for example we could start allowing offline modifications from provider IOServiceOpen() onwards, before registering as a provider with a path. If the process doesn't actually need to become a provider, it just stays in this state until it's done (IOServiceClose() or process exits).

If it is helpful, we can also allow entire process hierarchies to modify offline roots, in a similar way to how we check if a process was spawned by a user by walking up the parent process chain.

[wilbaker]

Can we have these processes, or at least a parent process of these processes register with the kext?

We could have these processes register with the kext. In both the cases called out in the description:

• VFS4G from modifying the .git/hooks a as part of mounting
• gvfs repair from being able to fix up files in the .git folder

We own the code and I don't think it would be a big deal for the process to make a call to register itself.

If the process doesn't actually need to become a provider, it just stays in this state until it's done (IOServiceClose() or process exits).

There are no plans to have these processes become providers. They might launch the provider process as part of doing their work, but we could have them unregister with the kext before doing so (in case that simplifies anything).

CC: @kewillford as FYI and to double check my statements on provider/process lifetimes

[wilbaker]

If it is helpful, we can also allow entire process hierarchies to modify offline roots, in a similar way to how we check if a process was spawned by a user by walking up the parent process chain.

We might need this, I'll have to check if gvfs repair launches any child processes.

[pmj]

We could have these processes register with the kext. In both the cases called out in the description:

• VFS4G from modifying the .git/hooks a as part of mounting
• gvfs repair from being able to fix up files in the .git folder

We own the code and I don't think it would be a big deal for the process to make a call to register itself.

Sounds good! Can you or someone else point me at the code where I'd need to insert the registration? That's probably more time-effective than my hunting around for it as it's presumably in corners that I'm deeply unfamiliar with.

There are no plans to have these processes become providers. They might launch the provider process as part of doing their work, but we could have them unregister with the kext before doing so (in case that simplifies anything).

OK, sounds like there's no point lumping it in with the provider user client. I'll create a new user client class for this purpose then, unless there's some other suggestion for how to identify the processes in question?

[wilbaker]

Can you or someone else point me at the code where I'd need to insert the registration?

Here is the Main method shared by all of the gvfs <verb> binaries:

VFSForGit/GVFS/GVFS/Program.cs

Line 13 in 6cf59a9

public static void Main(string[] args)

I think it would make sense to add a RegisterWithKernel type method to IKernelDriver that would be a no-op on everywhere except in ProjFSKext.cs.

We could then call that method (GVFSPlatform.Instance.KernelDriver.RegisterWithKernel()) after the call to GVFSPlatformLoader.Initialize() in Main.

We'll also need some Managed <-> native glue to get the call through to PrjFSLib, but that should be pretty minor.

I'll create a new user client class for this purpose then, unless there's some other suggestion for how to identify the processes in question?

I think that sounds good. Any sort of "smarts" (e.g. identifying allowed processes via name) are probably more fragile/brittle than simply allowing our processes to register and allowing our processes and their children to make modifications.

[pmj]

I think that sounds good. Any sort of "smarts" (e.g. identifying allowed processes via name) are probably more fragile/brittle than simply allowing our processes to register and allowing our processes and their children to make modifications.

Agreed. Other options I can think of are bundle identifier and code signing identity, but those are likely more complex and make things unnecessarily tricky for anyone using self-compiled versions of VFS4G.

We're not circumventing any normal security mechanisms with this, so I think having processes simply opt-in to write access without any kind of central authorisation is fine.

The simplest approach will be to opt-in globally for all virtualisation roots at once, but in principle we could make it a per-root thing. Opinions on that?