intrigeri:
> J. R. Okajima:
:::
> > Does your AppArmor setting allow reading "/etc/ld.so.cache" and
> > "/usr/lib/x86_64-linux-gnu/*.so*", but deny for "/live/image/..."?
>
> Using AppArmor with aufs (or overlayfs by the way) is a bit tricky; it
> generally requires adjusting the system's AppArmor policy a bit.
> That's why, for example, the Debian Live images disable AppArmor
> by default (see ConditionPathExists=!... in apparmor.service).
Thank you very much for the information.
Now I see the whole story (I hope). AppArmor accepts
"/usr/lib/x86_64-linux-gnu/*.so*" but denies "/live/image/..."
Let's make it clear.
Assume these two kernel internal functions (pseudo code for the
explanation).
VFS::open_systemcall(path)
{
open_body(path);
}
VFS::open_body(path)
{
brabra...;
err = apparmor(path);
if (err) {
log_msg(brabra);
return err;
}
err = fs_specific_open(path);
if (err) {
brabra...;
return err;
}
return success
}
- user program issues open(2) which is VFS::open_systemcall().
- VFS::open_systemcall() calls VFS::open_body() which tests AppArmor,
and if it succeeds, then calls fs_specific_open() such like
tmpfs_open(), iso9660_open(), or aufs_open().
- here, aufs_open() converts the given "path" to the one on the branch,
such as "/usr/lib/.." into "/live/image/usr/lib...", and calls
VFS::open_body() with the converted path.
aufs::aufs_open(path)
{
converted_path = branch_path(path);
open_body(converted_path);
}
- so VFS::open_body() is called twice, one for "/usr/lib/.." and the
other is "/live/image/usr/lib...", so does apparmor().
- and when apparmor() gets "/live/image/usr/lib...", it rejects
accessing by following its policy.
There may exist several options and variations to address this problem.
- modify the apparmor's policy to allow the branch path.
- add a parameter to VFS::open_body() which will be
+ to skip calling apparmor().
+ to give a non-converted path to apparmor().
And aufs::aufs_open() sets the parameter.
The first one looks good, but it may be hard to modify the large policy
files for users.
The second one (including its variation) doesn't look good, since it
blocks the narural behaviour of AppArmor or it must be redundant to test
the same path twice.
For me, there is one thing left to investigate. The BUG msg in
Christoph's kernel log file.
J. R. Okajima
