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. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor