On Tue, 2011-09-13 at 22:04 +0200, Guido Trentalancia wrote:
> On Tue, 2011-09-13 at 15:34 -0400, Stephen Smalley wrote:
> > On Tue, 2011-09-13 at 15:25 -0400, Stephen Smalley wrote:
> > > On Tue, 2011-09-13 at 21:18 +0200, Guido Trentalancia wrote:
> > > > Hello again.
> > > >
> > > > The security risk associated with the linkage of an old libsepol.a
> > > > static library is low due to the fact that the tools are usually built
> > > > from each component separately after all the libraries have been
> > > > previously built and installed.
> > > >
> > > > On Tue, 2011-09-13 at 14:48 -0400, Stephen Smalley wrote:
> > > > > On Tue, 2011-09-13 at 20:33 +0200, Guido Trentalancia wrote:
> > > > > > No, it doesn't currently ! If you want to try reproducing it, then you
> > > > > > should do so on a system which hasn't got it already installed (or make
> > > > > > sure you get temporarily rid of
> > > > > > $(PREFIX)/include/{selinux,sepol,semanage} and
> > > > > > $(LIBDIR)/lib{selinux,sepol,semanage}.* first).
>
> [cut]
>
> > I suppose the one thing that might not be clear is that the Makefile
> > orders the SUBDIRS in order of dependency, so that we build and install
> > libsepol first, then libselinux, and so on such that the headers and
> > libraries required to build each component are already installed before
> > we build that component.
>
> It is up to the maintainer to keep the SUBDIRS variable ordered
> (according to the dependency relations).
>
> See for example:
>
> http://www.gnu.org/s/hello/manual/make/Phony-Targets.html#Phony-Targets
> http://www.gnu.org/s/hello/manual/automake/Subdirectories.html
>
> > In your case, the sepol headers should have
> > already been installed before trying to build libselinux, and I don't
> > know why that didn't happen for you unless your make reorders SUBDIRS
> > internally or the make install in libsepol failed to complete (but I
> > wouldn't expect it to proceed in that case).
>
> The make tool should not reorder variables in any case.
>
> I did not issue a "make install" (yet). I did just issue "make" from the
> top-level directory.
>
> I am not building the components separately, I am building the whole
> bundle (tools + libraries) from the top-level directory of the git
> version. That's the point.
I, recently, applied a patch which changed the top level default from
install to all. sds says the 'right' way to build the git tree WAS to
call "make DESTDIR=~/out" (Remember the default was to install). Since
I changed the default target the new way to build out of the tree is to
call "make DESTDIR=~/out install"
I have no plans at this time to revert my commit which changed the
default from 'install' to 'all'. It is just flat out totally wrong that
cloning the git tree and typing make can break your running system.
Period. I agree that we must be certain not to break anyone who decides
to still use 'make DESTDIR=~/out install' method. Note: I'm fine that
this means I'm forcing sds to use the install target instead of the
default target from here out. The old default target was a very bad
idea. If you know you need to type DESTDIR= you can also know to type
'install.' If this doesn't work, I need to fix it. (It doesn't work
for me, but I'm not certain why just yet)
Personally, I'd like to see just 'make' at the top level dir build
properly and I think your patches get us most of the way there without
(further) breaking the building method that sds prefers.
If you get your best patch which does nothing but allow us to just type
'make' at the top level dir and it builds everything properly in place,
I'll review and probably commit such a patch.
-Eric
--
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.
