On Thu, Feb 14, 2013 at 9:05 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Wed, Feb 13, 2013 at 11:07:49AM +0200, Dmitry Kasatkin wrote: >> User space tools use getxattr() system call to read values of extended >> attributes. getxattr() system call uses vfs_getattr(), which for "security." >> namespace might get a value of the xattr indirectly from LSM via calling >> xattr_getsecurity(). For that reason value set by setxattr and read by getxattr >> might differ. >> >> Here is an example of SMACK label, which shows that set and read values are >> different: >> >> setfattr -n security.SMACK64 -v "hello world" foo >> getfattr -n security.SMACK64 foo >> # file: foo >> security.SMACK64="hello" >> >> EVM uses vfs_getxattr_alloc(), which directly reads xattr values from the file >> system. When performing the file system labeling with digital signatures, it is >> necessary to read real xattr values in order to generate the correct signatures. >> >> This patch adds the virtual "integrity." name space, which allows to bypass >> calling LSM and read real extended attribute values. >> >> getfattr -e text -n integrity.SMACK64 foo >> # file: foo >> integrity.SMACK64="hello world" > > Without knowing anything about xattr or LSM, to me it is odd that I > write an xattr using name "security.SMACK64" and read back the same > attribute using different name "integrity.SMACK64". > It might sound like that, but writing and reading security attributes, might give different results in security. namespace. We cannot break userspace and change semantics of calls. This is a trivial workaround which: (1) does not to break userspace and (2) does not require user space modifications. Please suggest anything else? - Dmitry > Thanks > Vivek -- 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
