On Wednesday, November 03, 2010 03:02:11 pm Eric Paris wrote: > On Wed, Nov 3, 2010 at 1:57 PM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > On Wednesday, November 03, 2010 01:38:33 pm Mimi Zohar wrote: > >> > > 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 > >> > >> Sorry I dropped the ball. Was expecting some kind of response to my > >> question above, and then forgot about it. > >> > >> All of the 'security' xattrs were moved to fsmagic.h, including > >> capability. Not only those that EVM protects, but others like > >> XATTR_NAME_SMACKIPIN/OUT (based on Casey's request). > > > > If user space has to know the exact contents of a string in order to do > > something that the kernel understands, then its part of a public API. > > I've made my own define and released a new copy of libcap-ng. So, if the > > contents of the string ever change, or becomes deprecated, you'll now > > have user space apps using the old values no matter what. > > You're right Steve, it is ABI, we broke it, and we can fix it. What > are you having to define and what are you including. What files did > you used to get these defines from? I did this: #define XATTR_CAPS_SUFFIX "capability" #define XATTR_SECURITY_PREFIX "security." #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX 2 of them came from capability.h. The other was not public sometime in the past. -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
