On Tue, 7 May 2002, Chris Wright wrote: > Unfortunately, simply adding the existing inode_ops->permission() hook > into exec_permission_lite() can be problematic. exec_permission_lite() > is called with the dcache lock held, and modules that sleep > in the inode_ops->permission() hook will cause trouble. In addition to avoiding sleeping operations, the security module has to ensure that it does not call a locking dcache operation, e.g. d_find_alias or d_path, during any hook called from this function. This might be an issue for some modules that try to audit a pathname, forcing them to return -EAGAIN if they need to call the dcache. > As Stephen Smalley suggested, one option is to add a new hook that is > aware of the locking paradigm. Specifically, this hook would return > -EAGAIN if it needed to force the kernel to release the dcache lock and > retry by calling full permission(), or return 0 on success of course. > > This is still not perfect, because exec_permission_lite() calls capable(), > which could, in theory, sleep in some modules. Another option is to > change the prototype of exec_permission_lite() so that it can unlock > before calling the standard permission() hook. This option has the same > issue wrt. capable() as first option. > > Both of these options are attached as patches. Neither feels > particularly clean, and I'd welcome alternatives. The second option seems to invalidate the whole point of the dcache fastwalk changes, only retaining the optimization when the Linux DAC logic would deny access. I'd vote for the first option. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue May 07 2002 - 06:23:25 PDT