Merge ~u-d/apparmor-profiles:thunderbird/launcher into ~apparmor-dev/apparmor-profiles/+git/apparmor-profiles-old:master

"xr" is not a valid permission set (except for deny rules). Please choose which exec mode (Cx, Px, ix, Ux or one of the fallback modes) you want to use ;-)

This looks good, but I have one question and would like to see one issue fixed.

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).

> 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.

You're right. Sorry I was confused.

Ulrike: so only my other question remains pending :)

Updates on this front: https://bugs.debian.org/874100 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855346#60.

Sorry for off-topic, but could you elaborate this:

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

So what are the AppArmor guidelines for these merge/separate usr exactly?

> So what are the AppArmor guidelines for these merge/separate usr exactly?

If I got Simon's explanation right: use alternations like /{usr/,}bin/xyz for stuff that's typically shipped in /bin or /lib (in order to support merged-/usr), and don't bother about stuff that's typically shipped in /usr already.

Status update: Vincas is going to rebase my last patch on top of the current profile and resubmit – thanks! :)

This was superseded by https://code.launchpad.net/~talkless/apparmor-profiles/+git/apparmor-profiles/+merge/332870 that was merged today.

What's the best way to reject this MR in Launchpad? I see I could delete it but it would be nice to keep this discussion archived.

Set the status to "Rejected", like I just did ;-)

> Set the status to "Rejected", like I just did ;-)

Thanks!