Re: FSEvents API and sandboxing
Re: FSEvents API and sandboxing
- Subject: Re: FSEvents API and sandboxing
- From: Dragan Milić <email@hidden>
- Date: Mon, 20 May 2019 23:34:57 +0200
> čet 16.05.2019., at 19.49, Dominic Giampaolo wrote:
Hi Dominic, thanks for kicking in and giving some more insights on the issue.
> I didn't know that kFSEventStreamEventFlagRootChanged is ignored in a
> sandboxed environment. That's unfortunate.
Well, I think my choice of words was a bit unfortunate. I didn't really want to
say that kFSEventStreamEventFlagRootChanged is ignored in a sandboxed
environment, but rather that it "doesn't work", so the actual behaviour is like
it's ignored.
> The "WatchRoot" flag is implemented on the client side of the FSEvents
> framework and it's just using kqueue's on each of the parent directories to
> watch for changes. You may be able to just use that.
And now that you explained how kFSEventStreamEventFlagRootChanged is actually
implemented, I understand why it doesn't work.
> Given that your app is sandboxed it probably isn't operating on files outside
> of its sandbox. If that's true then you may be able to just watch the
> parents up to the root of your sandbox and then stop. Sandbox containers
> effectively live in hidden locations that the user never sees or can modify
> so I think you're safe.
> If the files you're watching all live within your sandbox, the best thing is
> to work with paths that are relative to the root of your sandbox (or only
> construct full paths by prefixing the sandbox root just before you go to use
> the path).
None of the above is my case. I'll go into more details one more time, just to
explain my actual case, draw conclusion and ask for eventual workarounds. It
may be useful to someone else as well.
The application I'm working on is just a tiny client for the much larger
informational system. For its functioning, the system relies on a bunch of
configuration files, which can be scattered ALL OVER the filesystem(s). The
application needs to read those configuration files and present various
configuration options and parameters in a nice UI. The application also should
monitor configuration files for changes and act on any file change and update
its UI accordingly.
From the above it's clear the application doesn't operate on files within its
own sandbox. The read access to above mentioned configuration files is obtained
through a standard way in a sandboxed application, using NSOpenPanel/powerbox.
File changes are monitored using FSEvents API, with streams created with
kFSEventStreamCreateFlagFileEvents and kFSEventStreamCreateFlagWatchRoot flags.
Monitoring worked like a charm in a non-sandboxed application.
Now, when I started playing around with FSEvents API in a sandboxed
environment, I discovered an interesting thing. For the sake of clarity, let's
say the application needs to monitor a configuration file with full path being
"/Folder1/ Folder2/Folder3/File4". I expected that, in order to monitor this
file for changes in a sandboxed environment, I have to obtain (at least) read
access to it using some standard sandbox-friendly way (powerbox of temporary
entitlements). However, it turned out the application can monitor changes to
the file without obtaining any rights to it at all. After I thought about it,
it actually seemed logical; fseventsd daemon registers changes to the file and
will notify any process subscribed to file's path regardless of whether that
process has any access rights to a file on that path or not. FSEvents API is
strictly file-path based. Not that this "discovery" was of a particular
interest at all, since the application has already obtained read access to the
file in order to read configuration parameters. I just wanted to point it out
as an interesting effect due to FSEvents API being file-path based.
And so, the application is capable of monitoring all changes to the file even
in the sandboxed environment, except for kFSEventStreamEventFlagRootChanged.
And here is why… According to Dominic, root changes are actually implemented
using a series of kqueue's on directories "/Folder1", "/Folder1/Folder2" and
"/Folder1/Folder2/Folder3". Since kqueue is registered on a file descriptor
opened with at least O_EVTONLY flag passed, the whole
kFSEventStreamCreateFlagWatchRoot implementation fails, because even though the
application has read access to "/Folder1/ Folder2/ Folder3/File4" obtained
through the powerbox, it still has no rights to access any of three parent
directories. Opening file descriptors on those directories fails and
consequently kqueue's requiring those descriptors fail as well.
With all the above being said, it's clear even more than before that in order
to catch kFSEventStreamEventFlagRootChanged events in a sandboxed environment,
one has to watch the whole filesystem at path "/" unfortunately. I never really
liked that idea due to a flood of file events the application is not interested
in at all. And that was even before Dominic mentioned other concerns, such are
cpu usage, power consumption, and memory usage. For all those reasons, I'll try
to convince the "owner" of the application to drop notifications on
kFSEventStreamEventFlagRootChanged events. I hope they will accept it. I
strongly believe having it is not worthy of all drawbacks of watching changes
across the all filesystems at "/".
Of course, if anyone has some other ideas how to solve the problem completely,
I'm very willing to hear it.
-- Dragan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden