Joel Becker wrote: > I can't really comment on the concept, but if security folks agree, the > ocfs2 part looks fine. This is merely a bugfix/cleanup with a bit of cpu usage reduction. I noticed that EVM by error returns "struct xattr"->name == NULL and "struct xattr"->value != NULL if kstrdup(XATTR_EVM_SUFFIX, GFP_NOFS) failed, resulting in EVM security attribute not associated with inode and leak memory. The proposed (but now turned out to be incorrect) fix is http://marc.info/?l=linux-security-module&m=136965357007829&w=2 . But I also noticed that all of SELinux, Smack and EVM sets "struct xattr"->name a kstrdup()ed constant suffix. Therefore, if passing constant suffix ("const char *") rather than kstrdup()ed constant suffix ("char *") does not break "struct xattr"->name users, SELinux, Smack and EVM can omit kstrdup()ing their constant suffix. Therefore, I'm querying you whether changing from "char *name" to "const char *name" breaks your filesystem. If my proposal breaks your filesystem, I'm happy to fix only EVM code. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
