Stephen Smalley wrote:
On Wed, 2007-12-12 at 11:42 -0500, Joshua Brindle wrote:
Stephen Smalley wrote:
On Wed, 2007-12-12 at 11:02 -0500, Joshua Brindle wrote:
Stephen Smalley wrote:
On Wed, 2007-12-12 at 10:09 -0500, Joshua Brindle wrote:
Stephen Smalley wrote:
On Tue, 2007-12-11 at 15:13 -0500, Joshua Brindle wrote:
Joshua Brindle wrote:
This patch is necessary to build stable on RHEL4. CLIP uses the
current stable toolchain and supports RHEL4 as a target so we are
trying to upstream any magic that is necessary to build on that platform.
Ignore last patch, this one is actually against stable :)
What about just checking for the presence of /usr/include/sys/inotify.h
and disabling restorecond in its absence, similar to handling of PAMH
and AUDITH in newrole's Makefile? Then that could go into trunk too.
The next problem is that libselinux won't build on RHEL4 without
building the .lo files with --ftls-model=initial-exec. Do you have an
opinion on how to switch this on/off for building there?
We already have a TLSFLAGS definition for the .o files, so I suppose we
could have two definitions, one for the .o files and one for the .lo
files, and put them in the Makefile, and then you'd just build with make
SHARED_TLSFLAGS="-ftlsmodel=initial-exec" or whatever for RHEL4.
Or the other alternative would be to make the use of TLS completely a
build-time option, which would help for distributions where it isn't
supported at all. That shouldn't be too difficult; Manoj posted a patch
he was using for Debian a long time ago.
Ok, I see http://marc.info/?l=selinux&m=115807948020898&w=2
This makes TLS unnecessary at all though, right? I have no problem with
this as TLS makes me fairly uneasy anyway. Are you comfortable with
Manoj's patch? I didn't see any discussion of it at all on list after he
sent it..
I wasn't sure about unconditionally removing use of TLS (after all, if
it is supported, why not use it?), but a patch that made its use a
build-time option was ok with me if it didn't turn out to be too ugly to
maintain.
Well, if Manoj fixed the interfaces where it is unnecessary I'd support
removing it, TLS seems like a horrible way to hack around thread unsafe
code to me. What do we gain by fixing interfaces to not need it but use
it anyway?
Sure - in cases where tls wasn't truly needed at all, it should be
removed. But in cases where it was replaced by mutexes and the like,
there is an obvious tradeoff and we don't necessarily want to impose
that on systems that support tls (although I have no idea as to the real
performance tradeoffs there).
Ok, so the matchpathcon potion of the patch is ok and we can make TLS
optional for setrans_client?
I'll start working on this, is it ok for both stable and trunk or do you
hesitate about putting it in stable?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
