Comment 58 for bug 1751005

Revision history for this message
Kasoroth (kasoroth) wrote :

I ran into a similar problem on Ubuntu 17.10 that I think is related to the apparmor profile, because it appeared recently, but has gone away with the newest release. I have an ODT file (in my home folder) that has no ".odt" at the end of the filename.

It has never had problems in the past (Nautilus recognizes the file type from the contents, and launches LibreOffice, which would open the file successfully), but suddenly it started giving me an access denied message, which went away if I added ".odt" to the name. Now with the newest release, it works again without the ".odt".

Confined apps seem like a good idea, but seeing the variety of different problems that this change has caused (and will probably cause in the future as more apps apply confinement) makes me a bit concerned about the overall confinement strategy in general, not just for LibreOffice.

It seems like trying to make a universal definition of what file names and locations are appropriate for an app to access is an impossible task. The problem is that in a broad conceptual sense, there are sort of three classes of files:
System Files: need to be protected from untrusted users and untrusted apps. OS determines names and directory structure
App Files: owning app needs has full automatic access, and chooses names and sub-directory structure.
User Files: user has full access, and chooses names and sub-directory structure.

It seems to me that a better approach would be to give each app one specific folder that it has completely free access to read and write "app-owned" files, like settings, saved games (maybe "~/.local/share/appname" or "~/Settings/Apps/appname"), and then have specific "Trusted File Pickers" (for example, Nautilus, or a system-provided Open/Save window) that could temporarily give the app permission to access a specific file selected by the user.

I don't know if apparmor is capable of doing this sort of thing, but it seems like a better general approach to app confinement. I don't want an untrusted application to freely read or write everything in my home folder, potentially stealing personal information, or deleting/encrypting my documents. I also don't want an app to be prevented from accessing a file that I explicitly try to open with it, just because of where it's stored, or how the filename is formatted.

The one downside I can see for a system like I proposed is that it would make it very hard for confined applications to provide their own custom Open/Save windows, but I think that would be a reasonable trade-off for having more security.