I have looked at this for Jaunty and have a patch that fixes this for all but 1 case in the kernel. That one case however requires a larger change and need further investigation. That one case still requires
owner @{HOME}/.Private/** rw, be added to profiles.
Testing in Karmic has shown that the security_path_XXX hooks work as expected and that rmdir, unlink, mknod, mkdir, link, symlink all work. There is a single known regression case (dentry_open) where the name loop back occurs, resulting in both the encrypted and unencrypted paths being reported.
I have looked at this for Jaunty and have a patch that fixes this for all but 1 case in the kernel. That one case however requires a larger change and need further investigation. That one case still requires
owner @{HOME}/.Private/** rw, be added to profiles.
Testing in Karmic has shown that the security_path_XXX hooks work as expected and that rmdir, unlink, mknod, mkdir, link, symlink all work. There is a single known regression case (dentry_open) where the name loop back occurs, resulting in both the encrypted and unencrypted paths being reported.