On Wed, 2007-01-31 at 20:20 +0800, qin an wrote: > > inode_init_security is only one of the hooks > > you need to be concerned with. d_instantiate > > is another. There are several hooks with > > "xattr" in their names, and depending on your > > nefarious purposes you may need to address > > them as well. > > > > Yes, I used the inode_init_security to set xattr when I created a new > file, and d_instantiate to get the xattr from inode (one of parameters > of d_instantiate) and set in dentry when I open that file. > > I just check the two functions only to use > > # echo "my local file" > localfile > // the inode_init_security take into affect, and can see the xattr by > getfattr. > # cat localfile > // in inode_permission, I can not get the right xattr via the getxattr > > I search all the mailing list and found some one met the same problem, > but I didn't get any information about the solution. > > Could you give me some advices,thanks > > > The SELinux code is currently your best example > > of an LSM module that uses the interfaces. > > SELinux uses the information in sophisticated > > ways, so don't let the complexity of the code > > scare you. It is possible to use more simply. > > > > My code is similar as the SELinux in the two functions mentioned > above. I have studied SELinux for some days, and found it was more > complex and was not suitable to my job, so I have to rewrite the > codes.
Except that SELinux works, and your code apparently doesn't. In any event, it is difficult to diagnose the bug in your code without seeing it. If getfattr is showing you the correct attribute on the new file, then the bug lies in your code for getting the attribute in inode_permission. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
