Makefile change to disable restorecond

PATCH In review Joshua Brindle 2 participants 12 messages Dec 11, 2007 – Dec 12, 2007 SELinux security module

Share & tools

Joshua Brindle

author

2007-12-11 20:05 UTC #0 lore raw

PATCH 1/1 Makefile change to disable restorecond

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.

policycoreutils/Makefile (working copy) renamed from policycoreutils/Makefile (revision 2696) +5 -1

Index: trunk/policycoreutils/Makefile
===================================================================
@@ -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; \

Makefile (working copy) renamed from Makefile (revision 2696) +0 -0

Index: trunk/Makefile
===================================================================
@@ -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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

author

2007-12-11 20:13 UTC #1 lore raw

Quoted 2 lines · 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.

Ignore last patch, this one is actually against stable :)

Makefile (working copy) renamed from Makefile (revision 2677) +5 -1

Index: policycoreutils/Makefile
===================================================================
@@ -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; \

Makefile (working copy) renamed from Makefile (revision 2677) +0 -0

Index: Makefile
===================================================================
@@ -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

2007-12-11 20:19 UTC #2 lore raw

Quoted 6 lines · Joshua Brindle

Quoted 4 lines · 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.
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.

Quoted 30 lines

Index: policycoreutils/Makefile
===================================================================

Makefile (working copy) renamed from Makefile (revision 2677) +5 -1

@@ -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 (working copy) renamed from Makefile (revision 2677) +2 -0

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

Signature · 8 lines

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

author

2007-12-12 00:07 UTC #3 lore raw

Quoted 7 lines · Stephen Smalley

Quoted 5 lines · Joshua Brindle
Quoted 3 lines · 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.

Quoted 7 lines

Quoted 2 lines
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?

Makefile (working copy) renamed from Makefile (revision 2696) +7 -1

@@ -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; \

Stephen Smalley

Acked-by

2007-12-12 15:40 UTC #4 lore raw

Quoted 24 lines · Joshua Brindle

Quoted 9 lines · Stephen Smalley
Quoted 7 lines · Joshua Brindle
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 2 lines
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?
Makefile (working copy) renamed from Makefile (revision 2696) +1 -1
@@ -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

Makefile (working copy) line 11

Quoted 10 lines

Makefile (working copy) renamed from Makefile (revision 2696) +6 -0

 
+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 <[email protected]>

Merge at will.

Signature · 8 lines

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

author

2007-12-12 15:09 UTC #5 lore raw

In reply to Stephen Smalley

Quoted 7 lines · Stephen Smalley

Quoted 5 lines · Joshua Brindle
Quoted 3 lines · 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.

Quoted 7 lines

Quoted 2 lines
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?

Stephen Smalley

2007-12-12 15:35 UTC #6 lore raw

Quoted 13 lines · Joshua Brindle

Quoted 12 lines · Stephen Smalley
Quoted 9 lines · Joshua Brindle
Quoted 5 lines · 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.
Ignore last patch, this one is actually against stable :)

Quoted 8 lines

Quoted 4 lines
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.

Signature · 8 lines

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

author

2007-12-12 16:02 UTC #7 lore raw

Quoted 30 lines · Stephen Smalley

Quoted 15 lines · Joshua Brindle
Quoted 13 lines · Stephen Smalley
Quoted 10 lines · Joshua Brindle
Quoted 4 lines · 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.
Ignore last patch, this one is actually against stable :)
Quoted 7 lines
Quoted 5 lines
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.

Quoted 5 lines

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

Stephen Smalley

2007-12-12 16:11 UTC #8 lore raw

Quoted 41 lines · Joshua Brindle

Quoted 34 lines · Stephen Smalley
Quoted 17 lines · Joshua Brindle
Quoted 15 lines · Stephen Smalley
Quoted 12 lines · Joshua Brindle
Quoted 6 lines · 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.
Ignore last patch, this one is actually against stable :)
Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
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.

Quoted 5 lines

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.

Signature · 8 lines

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

author

2007-12-12 16:42 UTC #9 lore raw

Quoted 47 lines · Stephen Smalley

Quoted 45 lines · Joshua Brindle
Quoted 43 lines · Stephen Smalley
Quoted 20 lines · Joshua Brindle
Quoted 17 lines · Stephen Smalley
Quoted 13 lines · Joshua Brindle
Quoted 5 lines · 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.
Ignore last patch, this one is actually against stable :)
Quoted 9 lines
Quoted 6 lines
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.

Quoted 9 lines

Quoted 3 lines
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?

Stephen Smalley

2007-12-12 16:47 UTC #10 lore raw

Quoted 65 lines · Joshua Brindle

Quoted 58 lines · Stephen Smalley
Quoted 49 lines · Joshua Brindle
Quoted 41 lines · Stephen Smalley
Quoted 28 lines · Joshua Brindle
Quoted 15 lines · Stephen Smalley
Quoted 11 lines · Joshua Brindle
Quoted 7 lines · 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.
Quoted 10 lines
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
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..
Quoted 5 lines
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.

Quoted 4 lines

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

Signature · 8 lines

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

author

2007-12-12 16:59 UTC #11 lore raw

Quoted 72 lines · Stephen Smalley

Quoted 70 lines · Joshua Brindle
Quoted 68 lines · Stephen Smalley
Quoted 55 lines · Joshua Brindle
Quoted 45 lines · Stephen Smalley
Quoted 25 lines · Joshua Brindle
Quoted 21 lines · Stephen Smalley
Quoted 16 lines · Joshua Brindle
Quoted 6 lines · 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.
Ignore last patch, this one is actually against stable :)
Quoted 11 lines
Quoted 7 lines
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.
Quoted 7 lines
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.
Quoted 4 lines
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.

Quoted 9 lines

Quoted 2 lines
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?