[apparmor] Failed name lookup - disconnected path

[John Johansen]

On 07/13/2010 06:52 AM, Dr. David Alan Gilbert wrote:
> Hi,
>   I'm messing about trying to put a profile together for the chromium
> browser (I use the daily ppa's on Lucid).
> 
> I've got a few weird problems I'm seeing (I've currently got it in
> Complain mode); in particular it seems to be having problems
> with some font accesses:
> 
> [10879.975494] type=1502 audit(1279029320.974:21255):  operation="file_mmap" info="Failed name lookup - disconnected path" error=-116 pid=7399 parent=2350 profile="/usr/lib/chromium-browser/chromium-browser**//null-10" requested_mask="::r" denied_mask="::r" fsuid=1000 ouid=0 name="usr/share/fonts/truetype/msttcorefonts/Arial.ttf"
> 
> What causes a 'disconnected path' error? I note the name doesn't
> start with a / which I'm guessing is related.
> 
yes, that is how apparmor expresses a path that it can't connect.

There are a couple things that can cause disconnected paths.
1. revalidation of a file that was opened outside of the namespace.  This happens when a file has been opened
   and passed to a process (either through inheritance or ipc) and the file's labeling does not match the
   current profile.

   AppArmor then tries to validate access for the file be looking up its current name and using that
   for the current profile.  However if the file exists outside the current namespace then it can not get
   the full name (its not connected to a valid root for the task).

   This does not apply for chroots as AppArmor usually* resolves them to the fs root instead of the chrooted
   dir.  *there is a profile flag that will change this behavior.

2. The file is on a device that has been lazily unmounted, in which case its mount has been removed from
   the mount tree and it is no longer connected to the ds root for the namespace.


Unfortunately AppArmor's ability to deal with these types of files is limited at the moment.  Basically you
are limited to relying on the profile labeling on the opened file, or delegation.

When files are opened AppArmor labels the kernel file object with which profile the file was opened
under.  When the file is passed this labeling is used to determine whether the file has previously
been validated for access under the tasks profile and if not a revalidation is forced.  If the labeling
is the same then you won't get these messages.

Alternately AppArmor currently does two forms of implicit delegation, unconfined tasks implicitly delegate
their open files to tasks they launch, and deleted files (with no links) are implicitly delegated.
Unfortunately full delegation is not implemented yet.

In your case the file was opened by a task confined by /usr/lib/chromium-browser/chromium-browser**//null-10
The //null-10 appended to /usr/lib/chromium-browser/chromium-browser** is special, it indicates this is
a learning profile that was launched when a task confined by /usr/lib/chromium-browser/chromium-browser**
It happens when a profile in learning (complain) mode executes a program that the current confining profile
does not have an x rule for (so AA doesn't know what profile to attach).

The easiest way to deal with this right now is to add an ix rule to /usr/lib/chromium-browser/chromium-browser** for the program that is under //null-10, reload the profile and restart chromium.  Look in
the log for apparmor entries exec and /usr/lib/chromium-browser/chromium-browser**//null-10 as the target

Unfortunately the tools don't handle this, so its somewhat of a manual process at the moment.

> My apparmor profile is:
> http://www.treblig.org/debug/usr.lib.chromium-browser.chromium-browser
>