On Wednesday, November 03, 2010 03:02:11 pm Eric Paris wrote:
quoted text
> On Wed, Nov 3, 2010 at 1:57 PM, Steve Grubb <sgrubb@redhat.com> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/