[PATCH] [STABLE] Makefile change to disable restorecond

[PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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.


Index: trunk/policycoreutils/Makefile
===================================================================
--- trunk/policycoreutils/Makefile      (revision 2696)
+++ trunk/policycoreutils/Makefile      (working copy)
@@ -1,5 +1,9 @@
-SUBDIRS=setfiles semanage load_policy newrole run_init restorecond secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
+SUBDIRS = setfiles semanage load_policy newrole run_init secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
 
+ifndef NO_INOTIFY
+       SUBDIRS += restorecond
+endif
+
 all install relabel clean indent:
        @for subdir in $(SUBDIRS); do \
                (cd $$subdir && $(MAKE) $@) || exit 1; \
Index: trunk/Makefile
===================================================================
--- trunk/Makefile      (revision 2696)
+++ trunk/Makefile      (working copy)
@@ -1,6 +1,8 @@
 SUBDIRS=libsepol libselinux libsemanage sepolgen checkpolicy policycoreutils # policy
 PYSUBDIRS=libselinux libsemanage
 
+export NO_INOTIFY
+
 ifeq ($(DEBUG),1)
        export CFLAGS = -g3 -O0 -gdwarf-2 -fno-strict-aliasing -Wall -Wshadow
        export LDFLAGS = -g



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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 :)

Index: policycoreutils/Makefile
===================================================================
--- policycoreutils/Makefile    (revision 2677)
+++ policycoreutils/Makefile    (working copy)
@@ -1,5 +1,9 @@
-SUBDIRS=setfiles semanage load_policy newrole run_init restorecon restorecond secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
+SUBDIRS=setfiles semanage load_policy newrole run_init restorecon secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
 
+ifndef NO_INOTIFY
+       SUBDIRS += restorecond
+endif
+
 all install relabel clean indent:
        @for subdir in $(SUBDIRS); do \
                (cd $$subdir && $(MAKE) $@) || exit 1; \
Index: Makefile
===================================================================
--- Makefile    (revision 2677)
+++ Makefile    (working copy)
@@ -1,6 +1,8 @@
 SUBDIRS=libsepol libselinux libsemanage checkpolicy policycoreutils # policy
 PYSUBDIRS=libselinux libsemanage
 
+export NO_INOTIFY
+
 ifeq ($(DEBUG),1)
        export CFLAGS = -g3 -O0 -gdwarf-2 -fno-strict-aliasing -Wall -Wshadow
        export LDFLAGS = -g



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Stephen Smalley]

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.

> 
> Index: policycoreutils/Makefile
> ===================================================================
> --- policycoreutils/Makefile    (revision 2677)
> +++ policycoreutils/Makefile    (working copy)
> @@ -1,5 +1,9 @@
> -SUBDIRS=setfiles semanage load_policy newrole run_init restorecon restorecond secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
> +SUBDIRS=setfiles semanage load_policy newrole run_init restorecon secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
>  
> +ifndef NO_INOTIFY
> +       SUBDIRS += restorecond
> +endif
> +
>  all install relabel clean indent:
>         @for subdir in $(SUBDIRS); do \
>                 (cd $$subdir && $(MAKE) $@) || exit 1; \
> Index: Makefile
> ===================================================================
> --- Makefile    (revision 2677)
> +++ Makefile    (working copy)
> @@ -1,6 +1,8 @@
>  SUBDIRS=libsepol libselinux libsemanage checkpolicy policycoreutils # policy
>  PYSUBDIRS=libselinux libsemanage
>  
> +export NO_INOTIFY
> +
>  ifeq ($(DEBUG),1)
>         export CFLAGS = -g3 -O0 -gdwarf-2 -fno-strict-aliasing -Wall -Wshadow
>         export LDFLAGS = -g
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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.
>   
So... like this?

--- policycoreutils/Makefile    (revision 2696)
+++ policycoreutils/Makefile    (working copy)
@@ -1,5 +1,11 @@
-SUBDIRS=setfiles semanage load_policy newrole run_init restorecond secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
+SUBDIRS = setfiles semanage load_policy newrole run_init secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
 
+INOTIFYH = $(shell ls /usr/include/sys/inotify.h 2>/dev/null)
+
+ifeq (${INOTIFYH}, /usr/include/sys/inotify.h)
+       SUBDIRS += restorecond
+endif
+
 all install relabel clean indent:
        @for subdir in $(SUBDIRS); do \
                (cd $$subdir && $(MAKE) $@) || exit 1; \



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Stephen Smalley]

On Tue, 2007-12-11 at 19:07 -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.
> >   
> So... like this?
> 
> --- policycoreutils/Makefile    (revision 2696)
> +++ policycoreutils/Makefile    (working copy)
> @@ -1,5 +1,11 @@
> -SUBDIRS=setfiles semanage load_policy newrole run_init restorecond secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
> +SUBDIRS = setfiles semanage load_policy newrole run_init secon audit2allow audit2why scripts sestatus semodule_package semodule semodule_link semodule_expand semodule_deps setsebool po
>  
> +INOTIFYH = $(shell ls /usr/include/sys/inotify.h 2>/dev/null)
> +
> +ifeq (${INOTIFYH}, /usr/include/sys/inotify.h)
> +       SUBDIRS += restorecond
> +endif
> +
>  all install relabel clean indent:
>         @for subdir in $(SUBDIRS); do \
>                 (cd $$subdir && $(MAKE) $@) || exit 1; \

Yes.

Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>

Merge at will.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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..



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Stephen Smalley]

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).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] [STABLE] Makefile change to disable restorecond

[Joshua Brindle]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.