Re: free inode security blob

From: Chris Wright (chrisat_private)
Date: Fri Dec 07 2001 - 08:45:07 PST

  • Next message: Jacques Gelinas: "Re: Anyone tried the "vserver" patch?"

    (sorry, i mean to include the lsm list on the last reply).
    tongcd, you may also find useful lsm help on the lsm list.
    
    * Chris Wright (chrisat_private) wrote:
    > * tongcd (tongcdat_private) wrote:
    > > Could anybody give me some hint about the following question?  Thanks
    > > 1.  I use linux security module to alloc a security blob to each inode, but when
    > >     i want to cleanup the module ,i decide to free these alloced memory from inode struct,i want to travel through inode_in_use ,inode_unused,sb->s_dirty and sb->s_locked_inode ,but these are all static varieble,where is no way to use it in lsm module,could it be other ways to do it?
    > 
    > lsm attempts to make the minimal changes to the kernel required to
    > meet its requirements.  so static lists like you've mentioned have
    > not been exported just for lsm.  the proper way to handle this is to
    > maintain your own list in your module of the allocations you've made.
    > during the module_exit code, you can traverse these lists, and clean up
    > after yourself.  see the SELinux module for a good example of how to
    > handle this.  honestly, many lsm modules are coded with the intention
    > that they will not be removed until the machine is being rebooted, and
    > since lsm can control module unloading, this is not necessarily a bogus
    > assumption.
    > 
    > > why dte not do it?
    > 
    > i'm sure serge would accept patches ;-)
    > 
    > > 2.   iget4 call find_inode to find establishing inode linked in i_hash,(these inode all in inode_in_used and inode_unused links??)why iget call get_new_inode which use find_inode for a second time? If this question has post before,i am sorry.
    > 
    > it is possible for an inode to not be in hash.  so the first attempt
    > at find_inode in iget4 could fail.  notice find_inode must be called
    > with lock, so get_new_inode (which is called after the search failed,
    > and the lock is released) must re-obtain the lock and re-check the hash.
    > 
    
    -chris
    
    _______________________________________________
    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 : Fri Dec 07 2001 - 08:55:19 PST