[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=MiQsBvdtcr+isqagDYzKOFH0QVb9P=6aAxWVv@mail.gmail.com>
Date: Wed, 3 Nov 2010 15:02:11 -0400
From: Eric Paris <eparis@...isplace.org>
To: Steve Grubb <sgrubb@...hat.com>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Ozan Çağlayan <ozan@...dus.org.tr>,
James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Casey Schaufler <casey@...aufler-ca.com>,
David Safford <safford@...son.ibm.com>,
Dave Hansen <dave@...ux.vnet.ibm.com>,
Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH] security: move LSM xattrnames to xattr.h
On Wed, Nov 3, 2010 at 1:57 PM, Steve Grubb <sgrubb@...hat.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?
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists