--- qin an <[EMAIL PROTECTED]> wrote: > 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
Verify that you're using the right attribute name space. I also see that you're running your test as root. Your code will determine if that matters. Are you using a file system that supports extended attributes, do you have the xattr code enabled, etc. It looks like you are, but it never hurts to check. > My code is similar as the SELinux in the two > functions mentioned above. Have a closer look at your xattr functions then. inode_post_setxattr may take you by surprise if you're not careful. Also check your inode_alloc_security and inode_free_security hooks. What does your security blob look like? > I have studied SELinux for some days, and > found it was more > complex and was not suitable to my job, SELinux has a lot of code that deals with caching and transitions. If you put that aside and look at the data handling it works as an example. > so I have to rewrite the codes. I am curious about what sort of controls you're implementing. Casey Schaufler [EMAIL PROTECTED] - 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
