Can’t browse and view local HTML files in home folder

[Olivier Tilloy]

(initially reported on the ubuntu-phone mailing list: https://lists.launchpad.net/ubuntu-phone/msg19168.html)

With the apparmor confinement, it is impossible for a phone user to browse and view local HTML files stored in their home folder.
This security policy was initially put in place to avoid disclosing sensitive information stored on the filesystem. It would be good to find a middle-ground solution that allows browsing and viewing "legitimate" files in one’s home folder, while preserving a good security level.

[Matthew Exon (ubuntubugs-mexon)]

My suggestion is more of a generic solution to the app confinement problem.

Assume I start at the file manager and I tap on a file. It presents an "Open with" dialog showing the apps that can open that type of file. The dialog should show all apps that can handle that file type, regardless of whether they have permission to see that particular file.

Somewhere on that dialog should be a checkbox saying "permanently allow app to view files in this directory" and a drop-down that by default has the current directory selected, but allows you to select any parent directory instead (yea even unto the very root). Then you select the app you want to open it with. Apparmor is automatically reconfigured appropriately, and the app opens to show the file.

It should then be possible to revoke these permissions somewhere in System Settings / Security & Privacy / App permissions.

This is the closest I can think of to a "I don't care about your stupid confinement model, just get the hell out of my way and never bother me again" button, which is precisely what I say (often out loud) when encountering app confinement issues in the present system. But it still allows reasonably tight security, especially if you make the effort to organise your files.

It would also allow apps to do things that aren't realistically feasible with a centralised file broker, such as custom "open file" dialogs, watching directories and automatically indexing new files, using named pipes, creating soft links, and all the other millions of things developers might think up that you couldn't possibly predict while designing an app confinement model.

[Emanuele Sorce (tronfortytwo)]

I found that is possible to browse and open local files, simply in the search bar put the file/directory path, for example: "/home/phablet/my-html-file.html"

[Olivier Tilloy (osomon)]

This doesn’t work here (and shouldn’t, really).
@Emanuele: can you please elaborate on how you achieve this? Are you using the app webbrowser-app, not an alternative browser?

[Emanuele Sorce (tronfortytwo)]

I am using the default web-browser, I am on vegetahd and rc-proposed. As soon as I can (sorry I cant right now) I will post the behaviour step by step. Sorry if I haven't answered before, but the notification mail fell on junk (i don't know why) and I saw it just now.

[Olivier Tilloy (osomon)]

Thanks Emanuele, I’ll be waiting for your feedback.

[Emanuele Sorce (tronfortytwo)]

Sorry if I write an extensive explaination just now, but I was a bit busy lately. The behaviour of the webbrowser-app can be divided in three categories when trying to open a file (or a folder) from local memory.
1 - Unexistent file or folder: will return the "Network Error".
2 - Existing file or folder, but without permission in that directory. For example writing "/usr/" should access the /usr/ folder, but the webbrowser doesn't have enought permission to open it, the returning page is a blank one, without any intestation or anything else.
3 - Existing file or folder, with permission. The directories webbrowser can open are as far as i know /home/phablet/Downloads and /home/phablet/.config/webbrowser and maybe the respective .cache and .local direcrories. In these directories is possible to browse and open files as shown in the screenshot I am attaching.
I hope it's an enought clear explaination.

[Olivier Tilloy (osomon)]

Indeed Emanuele, you’re absolutely right about those three cases. Note that the lack of feedback (blank page) when browsing to an existing file/directory whose access is denied is being tracked separately as bug #1503332.