So the answer, is most likely not great atm. Option 1: unconfined If you are coming from an unconfined bash/lintian then object delegation will take care of this for you (more on that below). However since you are seeing file_inherit messages that isn't the case. And you would need to change confinement such that bash/lintian is unconfined for this option to work atm.
Option 2: confined In this case you are currently limited to AppArmor acting as an ambient authority system, which basic means every confinement domain (profile) needs to enumerate all available accesses. As proposed by Loïc in comment #2 if you don't want to give man read access to the entire system you need to teach lintian to write to a specific location that is shared by both profiles. We do have 2 improvements that are in progress that are NOT currently available, but we should start planning for them from an interface perspective for snap. Both of the following features will require a new apparmor userspace (not a problem as snap vendors apparmor) and a newer kernel. I. Controlled Object Delegation (hopefully 24.10 time frame) this is available today, via unconfined. Unconfined allows delegating its objects to any confined application. Unfortunately this currently is not available to confined applications. With controlled delegation, you add a rule to the source's profile (eg. lintian) that specifies which files open (fd objects) can be delegated to who (target profile eg. man). The target profile (man) will the access that descriptor under the source's (lintian's) authority. If a target tries to pass the descriptor off via SCM/dbus etc or inheritance, the descriptor will get revalidated against the new target, and denied if there isn't a rule allowing it in the original source (lintian). II. object labeling - again not available today, nor as good a fit for this situation. It is also further out than object delegation from landing. - this solution limits target location fstype - this solution only works if the source is creating or modifying the file or the files type, and may cause revocation of the file to other applications, even if not sharing a file descriptor - requires rules in both profiles, however they can be more abstract (even excluding location entirely) than the solution required today. The source (lintian/bash) marks the file being passed by setting its object label. The target (man) must have access to the object type that the file is tagged with via a rule in its profile. The object can then be passed/inherited and the inheritance check will let it through. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055402 Title: Though lintian call: error: troff: Segmentation fault To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/2055402/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
