On 09/17/2014 06:30 PM, Li, Li wrote: > Hello Seth, > > Thanks for the quick response! > > Well, I did a little bit more digging myself and looks like the problem I > have may not be hard/symb link issues. It's file system issue. > right
> The system I have use something called overlay-filesystem. > https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/Documentation/filesystems/overlayfs.txt?h=overlayfs.current > okay overlayfs does some interesting things > The link describe what it does. As I previously thought the two objects/files > are hardlink, well it actually may not be, it's the "same" file showing up in > both lower and upper layer. So essentially you have two mount points to the > same object. It also mean the lookup of a requested object can exist in two > "directory" if it exists on both upper and lower. I don't know how > significant this have on the AppArmor code, from what I look at, it walks > through dentry each time a file object is accessed. > yes, it is a stacked virtualfs, where the overlay filesystem presents inodes & dentries to the the system, and then loops back into the vfs with the corresponding mnt/dentry/inode of the underlying filesystem. > For example, by using overlayfs, we have a lower fs mounted on '/rom', and a > higher fs mounted on '/', you will find a exe file under both '/rom/bin/exe' > and '/bin/exe' exists. And it's not a "hard link". correct > For all practical purpose, all the access to the file is using upper fs, so > no one will even notice there're two fs. > Not so for apparmor, because of how this is put together in the kernel accesses to the overlay show up for each layer. So for your example, the access to /bin/exe will show up as a lookup to /bin/exe, followed by a lookup of /rom/bin/exe except with a twist (see below) > I did a bit debugging on the kernel AppArmor code, it looks like a "path" > lookup failed each time a file under '/bin/exe' is accessed. But if I run it > using '/rom/bin/exe', the lookup worked. I also looked at apparmor/path.c > code: > yes, this is because of how overlayfs setups the lower mnt > Let's say the path passed in is 'bin/exe', and walk through the code, the > function always return error -13, if the path name is the upper fs path. Hope > this might help figure out where the problem is. > again the problem is in how overlayfs sets up its overlay. To avoid having the submount showup in certain cases the way it does for aufs (another overlay filesystem) it uses clone_private_mount() which creates a disconnected private mount point to hide the fact that vfs is doing a loopback into the lower mount. The lower mount is disconnected from the namespace and apparmor notices this when it does its lookup, and since your profiles are not using the attach_disconnected flag it rejects the access to the lower mount which gets propogated back up through. Currently disconnected paths are a problem for apparmor, there is a crude work around, but the true fix has not landed yet. You can add the attach_disconnected flag onto the profile eg. profile /foo flags=(attach_disconnected) { } This will result in the disconnect path lookup being connected to the root so it will likely show up as /rom/bin/exe to apparmor (your regular userspace applications will still only see the single file /bin/exe). The other problem you have is that apparmor policy will need rules to allow access to these files. There is an alias command that can help with it. alias / -> /rom/, adding automatically will create rule aliases (essentially doubling the rules like you need). Eg. for the rule /bin/exe r, the alias generated would be /rom/bin/exe r, hope this helps john -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
