On 01/23/2014 03:42 PM, Christian Boltz wrote: > Hello, > > Am Donnerstag, 23. Januar 2014 schrieb Steve Beattie: >> It kind of points to a minor deficiency in aa_change_hatv()'s >> interface, in that you know you successfully changed to hat or not, >> but not which one. > > That sounds like we should find a way to change that ;-) > > Does aa_change_hatv internally know to which hat it switched?
yes it does > If yes, I'd propose to add another function similar to aa_change_hatv > that indicates the selected hat in its return value. > > (aa_change_hat(2) says the return value is zero on success, so changing > the return code of the existing function isn't a real option.) > Its more of how the current interface to the kernel works. Basically we get back either the size of bytes handled (success) or an error code. We could create a transactional system (whether fs, or network based) that would require both a write and a read, but thats not really much different than change_hat followed by getcon. We could try to get an ioctl (I'm not thrilled with this), and we won't get an apparmor specific syscall. Another option I have already mentioned is overloading some of the error code range, and having apparmor know about that, and remap them back in a change_hat2 fn. I'm not thrilled with that one either but it might work okay. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
