On Tuesday, October 12, 2010 09:40:34 am Mimi Zohar wrote: > On Tue, 2010-10-12 at 09:19 -0400, Steve Grubb wrote: > > On Tuesday, October 12, 2010 09:06:09 am Mimi Zohar wrote: > > > On Tue, 2010-10-12 at 14:14 +0300, Ozan ÃaÄlayan wrote: > > > > Cuma 02 Temmuz 2010 gÃnà (saat 03:16:01) James Morris ÅunlarÄ yazmÄÅtÄ: > > > > > On Thu, 1 Jul 2010, Mimi Zohar wrote: > > > > > > Make the security extended attributes names global. Updated to > > > > > > move the remaining Smack xattrs. > > > > > > > > > > > > Signed-off-by: Mimi Zohar <zohar@xxxxxxxxxx> > > > > > > Acked-by: Serge Hallyn <serue@xxxxxxxxxx> > > > > > > > > This drops > > > > > > > > #define XATTR_CAPS_SUFFIX "capability" > > > > #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX > > > > > > > > definitions from capability.h and puts them in xattr.h's #ifdef > > > > __KERNEL__ section making them invisible to userspace like libcap-ng > > > > causing build failures. > > > > > > > > Am I wrong? > > > > > > You're correct. It's the same reason that cap-ng.c has to define > > > 'security'. > > > > > > #ifdef VFS_CAP_U32 > > > > > > #include <attr/xattr.h> > > > #define XATTR_SECURITY_PREFIX "security." > > > > > > Am cc'ing Steve. > > > > So does this mean I need to provide more definitions for libcap-ng to > > work with future kernels or are you asking my opinion? My opinion is > > that if user space needs it to work correctly, please let it be > > available so I don't have to make my own define which may be inaccurate > > one day. > > > > Thanks, > > -Steve > > Before making any changes to the kernel xattr.h, I want to understand > the reason for two xattr.h files, one in /usr/include/linux/ and the > other in /usr/include/xattr/. /usr/include/linux/xattr.h contains those > elements not defined as __kernel__, while /usr/include/xattr/xattr.h > contains that and other definitions. Will changing the kernel xattr.h > version change both? > > As long as we're making this change, should 'security' also be defined > outside of the __kernel__ definitions? I guess no one fixed this before 2.6.36 was finalized. Removing the define has broke user space compilation for anything that works on file based capabilities. I can define it myself, but if the kernel folks ever change the string, then we have more than just a compile problem, we have runtime problems because I can no longer use the correct string. So, what was the gain for breaking user space? -Steve -- 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
