Remember a few weeks ago when I was figuring out how to read files? And how I learned to use apparmor profiles? And how this was tested by a Canonical employee? Well, imagine my surprise when, submitting my app, I discovered that you’re not allowed to request these apparmor permissions.
**Why did you tell me to use this, then!?! **
Ahem. Keeping in mind Hanlon’s razor, the explanation probably is that there’s no clear plan for how apps should access the file system. In this fog, various people are doing their best to understand the situation and explain it to others, but since no one really understands what’s going on, this advice may be contradictory. This is understandable, but that doesn’t make the situation any better. It’s hard to see how a plan will be formed, documented, and implemented in the month left before 13.10, especially with all the other work left to do.
I’m also displeased because this is exactly what I predicted in my previous post, an end-game where apps sit in their own little silos, not talking to each other—a betrayal of the Unix philosophy. But even I wasn’t pessimistic enough to think we’d get there in less than three weeks.
I asked about this on IRC, and the answer I got was, this is to protect your data from other apps. But I don’t want to protect this data from other apps. I want to let other apps come in and manipulate, delete, refile, and update the epub files. Beru was specifically designed not to assume that files in the library wouldn’t disappear between runs. And I want someone else to be able to write a better epub reader that can display all the books the user had been reading with Beru. But that can’t happen; instead users lock themselves into Beru with each book they add to the library. If I were trying to make money, this’d be great. If I want an awesome epub reader, not so much.
(And I can’t resist noting that, thanks to bugs #1197051 and #1224126, most apps’ “private” files are in fact vulnerable to any other app. This solution prevents us from sharing files we want shared, and shares the files we want to keep private.)
Now, the answer I got on IRC was only part of the true answer. In fact, this is done to protect the user from me, the app developer. They want the user to be able to run apps without worrying that they will access the user’s private files. Leaving aside the question of whether this is really necessary (somehow Linux hasn’t suffered a swarm of malicious shell scripts), the solution doesn’t require completely completely isolating the apps from one another; all you have to do is isolate the apps from the user’s “private” data. This is exactly what I was trying to do, in an ad hoc manner, by restricting Beru’s file system access to ~/Books.
But maybe there should be a formalized solution. One folder in the users’ home directory could become a free-fire zone for apps. Note that apps would still have their own private silos to retreat into; only those apps that wanted to share their data would use this special folder (or its subfolders) for their data. In short order, this folder would become a sort of HUB for sharing CONTENT.
When I first wrote this, it was with tongue firmly planted in cheek. But the more I think about it, the less cheek I taste. What does the planned content hub offer that this solution doesn’t? (A serious question, since I haven’t seen any plans for the content hub.) And is it really impossible to implement those missing features on top of a shared directory?
I’m being completely serious now: We could have a content hub tomorrow if we just decided that all apps should have RW access to ~/ContentHub. Want to give content to the hub? Just write a file there. Want to read all files of a given type in the hub? Just go through that directory and get the ones you want. Then we could add a simple API that wraps these operations, so you can access it directly from QML. But because we’re just writing files behind the scenes, the old apps that were doing this directly will work just fine with apps using the new API. And I’m sure that there must be a way to allow more fine-grained access to this directory. The first time an app tries to read (or, separately, write) a file of type X in ~/ContentHub, apparmor could catch it and pop up a dialog with “Deny”, “Allow once”, “Always allow for this type”, and “Allow for all types” options. Eventually, we could add an API to allow apps to request these privileges prior to trying to read a file, but the old method of try-it-and-see-what-happens would still work. “Sophisticated” apps could eventually use the content hub entirely through an API without knowing that there’s a filesystem behind it, while “simple” apps would just do bog-standard filesystem access without knowing what a content hub is.
So what am I missing? Why isn’t this what we’re doing?
Enough pontificating—where does this leave Beru? In order to comply with the siloization (it’s a perfectly cromulent word), Beru now looks for books in ~/.local/share/com.ubuntu.developer.rschroll.beru/Books. This defeats one of my original design goals of making it easy to move books between your computer and your phone. These changes bother me enough that I haven’t let them into master yet; they’re sitting in the separate restricted branch. If you’re tracking master, you don’t have to deal with this yet. I’m not sure what the way forward is, though. I don’t want to develop an intentionally hobbled application just to get into a single app store. But I also don’t want to maintain parallel branches. Perhaps it’s possible to have a single code base that can alter its behavior when run under confinement. Perhaps we should have the library directory be an option, and set it initially based on confinement. Perhaps I’ll just distribute click packages myself and forget about the app store. I don’t know yet, but I’d love to hear others’ opinions on the matter.