[apparmor] [Merge] ~u-d/apparmor-profiles:thunderbird/launcher into apparmor-profiles:master

[Simon McVittie]

On Sat, 01 Jul 2017 at 16:14:03 -0000, intrigeri wrote:
> > +  /usr/bin/exo-open rmix,
> > +  /{usr/,}bin/* Cx -> sanitized_helper,
> > +  /usr/bin/evince Pix,
> > +  /usr/bin/totem Pix,
> 
> Please use paths that work with merged-/usr i.e. for example
> /{usr/,}bin/evince. I've spent lots of time eliminating all these
> incompatibilities and would rather not see us add new ones now :)

tl;dr I'm not sure this is actually a problem, even with merged /usr.

There are three possible handlings of /usr:

* Separate /usr (traditional setup, e.g. Debian 8): low-level system
  utilities (enough to do basic disaster recovery and mount /usr) are
  in /bin, high-level/large binaries are in /usr/bin

* Merged /usr (Fedora, Debian with usrmerge): Everything is physically
  in /usr/bin, /bin -> /usr/bin is a symlink

* No /usr (Debian GNU/Hurd tried this for a while and decided it was
  too weird even for them): Everything is physically in /bin,
  /usr -> / is a symlink

For basic system utilities (those that are sometimes or always in /bin):

* Hard-coding /bin/sh in AppArmor profiles breaks "merged /usr"
* Hard-coding /usr/bin/sh breaks "separate /usr" and "no /usr"
* Alternations like /{usr/,}bin/sh work for everyone

For "high-level" things like GUIs, that nobody except the "no /usr"
faction would put in /bin:

* Hard-coding /bin/evince breaks everything except the rare "no /usr" case
* Hard-coding /usr/bin/evince breaks the rare "no /usr" case, but I'm
  not convinced that case exists in reality
* Alternations like /{usr/,}bin/evince work for everyone, but are
  unnecessary complexity if the "no /usr" case doesn't really exist

Does the "no /usr" case actually exist in practice? It seems to me that
its only advantage is some debatable conceptual elegance. The major
advantage of merged /usr is that it groups together all large read-only
OS files (/usr/bin, /usr/sbin, /usr/lib*, /usr/share) into a directory
that can easily be a separate read-only mount-point, without including
files that must be in the root filesystem and would prevent it from
being read-only (notably /etc).

-- 
https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276
Your team AppArmor Developers is requested to review the proposed merge of ~u-d/apparmor-profiles:thunderbird/launcher into apparmor-profiles:master.