Re: Problems with some of the current hooks

Previous message: Crispin Cowan: "Re: Port of secure fd handling to LSM"
In reply to: Stephen Smalley: "Re: Problems with some of the current hooks"
Next in thread: David Wagner: "Re: Problems with some of the current hooks"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

gregat_private

On Mon, Aug 06, 2001 at 09:13:29AM -0400, Stephen Smalley wrote:
> 
> The reason that I "guard" this call to bprm_ops->free_security (which I
> also did with the sb_ops->free_security call in fs/super.c:read_super)
> is to skip the call in the case where the alloc_security routine
> itself failed (it does a 'goto out;' just like the subsequent code
> on error).  Otherwise, I would need to rearrange the code after the
> out label and insert a new goto label that would skip the free_security
> call but do the rest of the cleanup processing.  Also, notice that there 
> is a precedent for this kind of guard - the existing code does a 'if
> (bprm.file) fput(bprm.file);' in the same code path.

Ah, it's on the error path.  No real speed reason here.  That makes
sense now.

thanks,

greg k-h

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module