[PATCH 1/2] libselinux: put libselinux.so.1 in /lib not /usr/lib

[PATCH 1/2] libselinux: put libselinux.so.1 in /lib not /usr/lib

[Eric Paris]

Commit 874bac80bbfbf0a5 incorrectly changed the default install location
of libselinux.so.1 from /lib to /usr/lib.  This patch fixes that problem
by reverting that portion of the change.

Signed-off-by: Eric Paris <eparis@redhat.com>
---
 libselinux/src/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 7680008..78874be 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -7,7 +7,7 @@ PYPREFIX ?= $(notdir $(PYTHON))
 # Installation directories.
 PREFIX ?= $(DESTDIR)/usr
 LIBDIR ?= $(PREFIX)/lib
-SHLIBDIR ?= $(PREFIX)/lib
+SHLIBDIR ?= $(DESTDIR)/lib
 INCLUDEDIR ?= $(PREFIX)/include
 PYLIBVER ?= $(shell $(PYTHON) -c 'import sys;print("python%d.%d" % sys.version_info[0:2])')
 PYINC ?= $(shell pkg-config --cflags $(PYPREFIX))
-- 
1.7.6.2


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

[PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Eric Paris]

At the moment we create a symlink:

/usr/lib/libselinux.so -> ../../lib/libselinux.so.1

This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
../../.  Instead create a symlink from

$LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1

Thus it works no matter what values one might use for LIBDIR and
SHLIBDIR.

Signed-off-by: Eric Paris <eparis@redhat.com>
---
 libselinux/src/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 78874be..bccc777 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -126,7 +126,7 @@ install: all
 	install -m 755 $(LIBSO) $(SHLIBDIR)
 	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
 	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
-	cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)
+	ln -sf $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)
 
 install-pywrap: pywrap
 	test -d $(PYLIBDIR)/site-packages/selinux || install -m 755 -d $(PYLIBDIR)/site-packages/selinux
-- 
1.7.6.2


--
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 1/2] libselinux: put libselinux.so.1 in /lib not /usr/lib

[Eric Paris]

On Wed, Sep 14, 2011 at 2:50 PM, Eric Paris <eparis@redhat.com> wrote:
> Commit 874bac80bbfbf0a5 incorrectly changed the default install location
> of libselinux.so.1 from /lib to /usr/lib.  This patch fixes that problem
> by reverting that portion of the change.
>
> Signed-off-by: Eric Paris <eparis@redhat.com>

Side note: with this patch the current master branch will again build
properly with DESTDIR= and install.  (using install instead of the
default target it still required)

-Eric


--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Stephen Smalley]

On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> At the moment we create a symlink:
> 
> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> 
> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> ../../.  Instead create a symlink from
> 
> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> 
> Thus it works no matter what values one might use for LIBDIR and
> SHLIBDIR.

I'm not sure this works the way you would want.  Consider rpm build of
libselinux - it does:
make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install

And then rpm collects up the files into the package.
But if the symlink encodes the full pathname used at make install time,
then it will be wrong on the final system when the rpm is installed.
Haven't actually tested that theory, but I think it is true.  Welcome to
hell.

> 
> Signed-off-by: Eric Paris <eparis@redhat.com>
> ---
>  libselinux/src/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> index 78874be..bccc777 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -126,7 +126,7 @@ install: all
>  	install -m 755 $(LIBSO) $(SHLIBDIR)
>  	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
>  	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
> -	cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)
> +	ln -sf $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)
>  
>  install-pywrap: pywrap
>  	test -d $(PYLIBDIR)/site-packages/selinux || install -m 755 -d $(PYLIBDIR)/site-packages/selinux

-- 
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Eric Paris]

On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> > At the moment we create a symlink:
> > 
> > /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> > 
> > This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> > ../../.  Instead create a symlink from
> > 
> > $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> > 
> > Thus it works no matter what values one might use for LIBDIR and
> > SHLIBDIR.
> 
> I'm not sure this works the way you would want.  Consider rpm build of
> libselinux - it does:
> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> 
> And then rpm collects up the files into the package.
> But if the symlink encodes the full pathname used at make install time,
> then it will be wrong on the final system when the rpm is installed.
> Haven't actually tested that theory, but I think it is true.  Welcome to
> hell.

error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
-> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1

GRRRRRR.   Every other package I see with similar symlinks seems to be
an autoconf package and I can't understand how they work.  What we have
isn't right, but I don't know how to fix it....

-Eric


--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

Hi Eric.

On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> At the moment we create a symlink:
> 
> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> 
> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> ../../.  Instead create a symlink from

See the patch that I posted earlier on. The same is also true for the
libsepol library and libsemanage does it differently but might need to
be patched too if you really want to create the link in LIBDIR instead
of in SHLIBDIR.

To be a 100% safe, the link could be created in both LIBDIR and
SHLIBDIR.

However my explanation is as follows. SHLIBDIR stands for "shared
libraries directory" while LIBDIR stands for "libraries directory".
Therefore the *versioned* executable library should go in SHLIBDIR and a
symbolic link should be created in SHLIBDIR from the *versioned*
executable library to the *unversioned* generic shared library name.
This is an aid for LD. In any case, ldconfig is going to create a link
if SHLIBDIR is in its search path. However if a link is not there,
ldconfig might create a different link for it always links to the most
recent versioned library executable.

> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> 
> Thus it works no matter what values one might use for LIBDIR and
> SHLIBDIR.

My advice is to always create the link and install the executable in
SHLIBDIR and forget LIBDIR for the shared libraries.

Please do not forget to drop the above bits from my patch (if you are
going to do it differently). And please, even more important, do not
forget about looking at libsepol and libsemanage too.

Thanks.

> Signed-off-by: Eric Paris <eparis@redhat.com>
> ---
>  libselinux/src/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> index 78874be..bccc777 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -126,7 +126,7 @@ install: all
>  	install -m 755 $(LIBSO) $(SHLIBDIR)
>  	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
>  	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
> -	cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)
> +	ln -sf $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)
>  
>  install-pywrap: pywrap
>  	test -d $(PYLIBDIR)/site-packages/selinux || install -m 755 -d $(PYLIBDIR)/site-packages/selinux



--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Eric Paris]

On Thu, 2011-09-15 at 03:41 +0200, Guido Trentalancia wrote:

> > $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> > 
> > Thus it works no matter what values one might use for LIBDIR and
> > SHLIBDIR.
> 
> My advice is to always create the link and install the executable in
> SHLIBDIR and forget LIBDIR for the shared libraries.

That is an interesting question, and maybe the right one.  Do we really
need a link from /usr/lib64/libselinux.so -> /lib64/libselinux.so.1 ?

Would it not be fine to just have the link:
/lib64/libselinux.so -> /lib64/libselinux.so.1 ?

I lean towards agreeing that Guido is right and dropping the link
in /usr/lib64 altogether.  Any arguments against?

-Eric


--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

Eric,

please see my patch.

You fix it like this:

diff -pruN selinux/libselinux/src/Makefile selinux-13092011/libselinux/src/Makefile
--- selinux/libselinux/src/Makefile	2011-09-09 20:12:55.992662259 +0200
+++ selinux-13092011/libselinux/src/Makefile	2011-09-13 03:30:08.882910143 +0200
@@ -126,7 +126,7 @@ install: all
 	install -m 755 $(LIBSO) $(SHLIBDIR)
 	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
 	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
-	cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)
+	cd $(SHLIBDIR) && ln -sf $(LIBSO) $(TARGET)

and then for the other libraries:

diff -pruN selinux/libsemanage/src/Makefile selinux-13092011/libsemanage/src/Makefile
--- selinux/libsemanage/src/Makefile	2011-09-09 20:12:56.008662374 +0200
+++ selinux-13092011/libsemanage/src/Makefile	2011-09-13 03:36:55.724150908 +0200
@@ -139,7 +139,7 @@ install: all
 	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
 	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
 	test -f $(DEFAULT_SEMANAGE_CONF_LOCATION) || install -m 644 -D semanage.conf $(DEFAULT_SEMANAGE_CONF_LOCATION)
-	cd $(LIBDIR) && ln -sf $(LIBSO) $(TARGET)
+	cd $(SHLIBDIR) && ln -sf $(LIBSO) $(TARGET)
 
 install-pywrap: pywrap 
 	test -d $(PYLIBDIR)/site-packages || install -m 755 -d $(PYLIBDIR)/site-packages
diff -pruN selinux/libsepol/src/Makefile selinux-13092011/libsepol/src/Makefile
--- selinux/libsepol/src/Makefile	2011-09-09 20:12:56.021662468 +0200
+++ selinux-13092011/libsepol/src/Makefile	2011-09-13 02:57:31.309865469 +0200
@@ -43,7 +43,7 @@ install: all
 	install -m 755 $(LIBSO) $(SHLIBDIR)
 	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
 	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
-	cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)
+	cd $(SHLIBDIR) && ln -sf $(LIBSO) $(TARGET)
 
 relabel:
 	/sbin/restorecon $(SHLIBDIR)/$(LIBSO)

You really want stuff in the shared library directory (SHLIBDIR) and not
in the library directory (LIBDIR).

Library directory is for storing auxiliary things such as static files
or modules (which could be shared libraries in turn but are not loaded
the normal way), usually in a separate directory tree.

The shared library directory instead is where all libraries executables
are stored (and sourced from). Usually the shared library directory is
in the search path configured for LD and so a symbolic link is also
desirable in the shared library directory and that link should point
from the unversioned library name to the target executable file itself
which is stored under the versioned library name.

Hope it helps.

Regards,

Guido

On Wed, 2011-09-14 at 16:21 -0400, Eric Paris wrote:
> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> > On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> > > At the moment we create a symlink:
> > > 
> > > /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> > > 
> > > This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> > > ../../.  Instead create a symlink from
> > > 
> > > $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> > > 
> > > Thus it works no matter what values one might use for LIBDIR and
> > > SHLIBDIR.
> > 
> > I'm not sure this works the way you would want.  Consider rpm build of
> > libselinux - it does:
> > make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> > SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> > 
> > And then rpm collects up the files into the package.
> > But if the symlink encodes the full pathname used at make install time,
> > then it will be wrong on the final system when the rpm is installed.
> > Haven't actually tested that theory, but I think it is true.  Welcome to
> > hell.
> 
> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> 
> GRRRRRR.   Every other package I see with similar symlinks seems to be
> an autoconf package and I can't understand how they work.  What we have
> isn't right, but I don't know how to fix it....
> 
> -Eric
> 



--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> > At the moment we create a symlink:
> > 
> > /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> > 
> > This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> > ../../.  Instead create a symlink from
> > 
> > $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> > 
> > Thus it works no matter what values one might use for LIBDIR and
> > SHLIBDIR.
> 
> I'm not sure this works the way you would want.  Consider rpm build of
> libselinux - it does:
> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> 
> And then rpm collects up the files into the package.

Yes, for example, as we were speculating earlier on in a different but
related thread, Fedora generally sorts out things in standard and
development packages at least for the libraries (because the libraries
can be both used "passively" or "actively" for further development).

So the executable belongs to the standard package and the link belongs
to the development package. Many other distributions also split
libraries in two packages (a standard one and a development one).

> But if the symlink encodes the full pathname used at make install time,
> then it will be wrong on the final system when the rpm is installed.

Ideally the link should be (re)created by the spec file. Otherwise, I
agree, a relative link should be used.

> Haven't actually tested that theory, but I think it is true.  Welcome to
> hell.

We can use a relative link instead of an absolute path and we could
install the link both in SHLIBDIR and LIBDIR. The rest would need to be
sorted out by distributions' automated build systems or individual
installers.

What do you say ?

Guido

> > 
> > Signed-off-by: Eric Paris <eparis@redhat.com>
> > ---
> >  libselinux/src/Makefile |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> > index 78874be..bccc777 100644
> > --- a/libselinux/src/Makefile
> > +++ b/libselinux/src/Makefile
> > @@ -126,7 +126,7 @@ install: all
> >  	install -m 755 $(LIBSO) $(SHLIBDIR)
> >  	test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
> >  	install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
> > -	cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)
> > +	ln -sf $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)
> >  
> >  install-pywrap: pywrap
> >  	test -d $(PYLIBDIR)/site-packages/selinux || install -m 755 -d $(PYLIBDIR)/site-packages/selinux
> 



--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Christopher J. PeBenito]

On 09/14/11 16:21, Eric Paris wrote:
> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
>>> At the moment we create a symlink:
>>>
>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
>>>
>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
>>> ../../.  Instead create a symlink from
>>>
>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
>>>
>>> Thus it works no matter what values one might use for LIBDIR and
>>> SHLIBDIR.
>>
>> I'm not sure this works the way you would want.  Consider rpm build of
>> libselinux - it does:
>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
>>
>> And then rpm collects up the files into the package.
>> But if the symlink encodes the full pathname used at make install time,
>> then it will be wrong on the final system when the rpm is installed.
>> Haven't actually tested that theory, but I think it is true.  Welcome to
>> hell.
> 
> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> 
> GRRRRRR.   Every other package I see with similar symlinks seems to be
> an autoconf package and I can't understand how they work.  What we have
> isn't right, but I don't know how to fix it....

Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like

install foo $(BINDIR)

it turns into

install foo $(DESTDIR)(BINDIR)

Then when you have your symlink you can do

ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

Hi Christopher !

Thanks for the idea.

On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
> On 09/14/11 16:21, Eric Paris wrote:
> > On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> >> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> >>> At the moment we create a symlink:
> >>>
> >>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> >>>
> >>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> >>> ../../.  Instead create a symlink from
> >>>
> >>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> >>>
> >>> Thus it works no matter what values one might use for LIBDIR and
> >>> SHLIBDIR.
> >>
> >> I'm not sure this works the way you would want.  Consider rpm build of
> >> libselinux - it does:
> >> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> >> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> >>
> >> And then rpm collects up the files into the package.
> >> But if the symlink encodes the full pathname used at make install time,
> >> then it will be wrong on the final system when the rpm is installed.
> >> Haven't actually tested that theory, but I think it is true.  Welcome to
> >> hell.
> > 
> > error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> > -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> > 
> > GRRRRRR.   Every other package I see with similar symlinks seems to be
> > an autoconf package and I can't understand how they work.  What we have
> > isn't right, but I don't know how to fix it....
> 
> Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like
> 
> install foo $(BINDIR)
> 
> it turns into
> 
> install foo $(DESTDIR)(BINDIR)
> 
> Then when you have your symlink you can do
> 
> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so

Yes, this is even better, although $(DESTDIR) is not necessary in the
target, as SHLIBDIR already includes (begins with) DESTDIR:

ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)

and we got rid of cd, pushd and popd. For a double link, add:

ln -sf $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)

I think the -f (force) flag for ln is useful and desired here (as the
user might implicitly want to override the link created automatically by
ldconfig).

Guido


--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Christopher J. PeBenito]

On 09/15/11 08:16, Guido Trentalancia wrote:
> Hi Christopher !
> 
> Thanks for the idea.
> 
> On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
>> On 09/14/11 16:21, Eric Paris wrote:
>>> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
>>>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
>>>>> At the moment we create a symlink:
>>>>>
>>>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
>>>>>
>>>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
>>>>> ../../.  Instead create a symlink from
>>>>>
>>>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
>>>>>
>>>>> Thus it works no matter what values one might use for LIBDIR and
>>>>> SHLIBDIR.
>>>>
>>>> I'm not sure this works the way you would want.  Consider rpm build of
>>>> libselinux - it does:
>>>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
>>>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
>>>>
>>>> And then rpm collects up the files into the package.
>>>> But if the symlink encodes the full pathname used at make install time,
>>>> then it will be wrong on the final system when the rpm is installed.
>>>> Haven't actually tested that theory, but I think it is true.  Welcome to
>>>> hell.
>>>
>>> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
>>> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
>>>
>>> GRRRRRR.   Every other package I see with similar symlinks seems to be
>>> an autoconf package and I can't understand how they work.  What we have
>>> isn't right, but I don't know how to fix it....
>>
>> Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like
>>
>> install foo $(BINDIR)
>>
>> it turns into
>>
>> install foo $(DESTDIR)(BINDIR)
>>
>> Then when you have your symlink you can do
>>
>> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so
> 
> Yes, this is even better, although $(DESTDIR) is not necessary in the
> target, as SHLIBDIR already includes (begins with) DESTDIR:
> 
> ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)

I think you're missing the point.  I said you need to stop specifying $(DESTDIR) as part of $(SHLIBDIR).  Otherwise you get the broken symlinks that Eric talks about above.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

On Thu, 2011-09-15 at 08:22 -0400, Christopher J. PeBenito wrote:
> On 09/15/11 08:16, Guido Trentalancia wrote:
> > Hi Christopher !
> > 
> > Thanks for the idea.
> > 
> > On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
> >> On 09/14/11 16:21, Eric Paris wrote:
> >>> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> >>>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> >>>>> At the moment we create a symlink:
> >>>>>
> >>>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> >>>>>
> >>>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> >>>>> ../../.  Instead create a symlink from
> >>>>>
> >>>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> >>>>>
> >>>>> Thus it works no matter what values one might use for LIBDIR and
> >>>>> SHLIBDIR.
> >>>>
> >>>> I'm not sure this works the way you would want.  Consider rpm build of
> >>>> libselinux - it does:
> >>>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> >>>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> >>>>
> >>>> And then rpm collects up the files into the package.
> >>>> But if the symlink encodes the full pathname used at make install time,
> >>>> then it will be wrong on the final system when the rpm is installed.
> >>>> Haven't actually tested that theory, but I think it is true.  Welcome to
> >>>> hell.
> >>>
> >>> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> >>> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> >>>
> >>> GRRRRRR.   Every other package I see with similar symlinks seems to be
> >>> an autoconf package and I can't understand how they work.  What we have
> >>> isn't right, but I don't know how to fix it....
> >>
> >> Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like
> >>
> >> install foo $(BINDIR)
> >>
> >> it turns into
> >>
> >> install foo $(DESTDIR)(BINDIR)
> >>
> >> Then when you have your symlink you can do
> >>
> >> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so
> > 
> > Yes, this is even better, although $(DESTDIR) is not necessary in the
> > target, as SHLIBDIR already includes (begins with) DESTDIR:
> > 
> > ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)
> 
> I think you're missing the point.  I said you need to stop specifying $(DESTDIR) as part of $(SHLIBDIR).  Otherwise you get the broken symlinks that Eric talks about above.

Yes, that's true. There must be a way of stripping DESTDIR from SHLIBDIR
to create another variable called RELATIVE_SHLIBDIR which is not
absolute but relative to DESTDIR.

And then use that relative variable for the source of the link:

ln -sf $(RELATIVE_SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)

and eventually:

ln -sf $(RELATIVE_SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)

Sorry for creating further confusion ! Hopefully it makes sense now...

Guido


--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Stephen Smalley]

On Wed, 2011-09-14 at 21:46 -0400, Eric Paris wrote:
> On Thu, 2011-09-15 at 03:41 +0200, Guido Trentalancia wrote:
> 
> > > $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> > > 
> > > Thus it works no matter what values one might use for LIBDIR and
> > > SHLIBDIR.
> > 
> > My advice is to always create the link and install the executable in
> > SHLIBDIR and forget LIBDIR for the shared libraries.
> 
> That is an interesting question, and maybe the right one.  Do we really
> need a link from /usr/lib64/libselinux.so -> /lib64/libselinux.so.1 ?
> 
> Would it not be fine to just have the link:
> /lib64/libselinux.so -> /lib64/libselinux.so.1 ?
> 
> I lean towards agreeing that Guido is right and dropping the link
> in /usr/lib64 altogether.  Any arguments against?

We didn't invent this paradigm; it just came from existing layout in
Fedora and is true of other libraries there as well.  See for
example /lib64/libz.so.N vs /usr/lib64/libz.so.  And note that the
symlink is owned by the -devel package rather than the base package, and
shouldn't be required for normal operation (and thus can live in /usr).
Of course nowadays they are proposing eliminating the distinction
between /foo and /usr/foo entirely (discussion at LPC).

-- 
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

On Thu, 2011-09-15 at 08:22 -0400, Christopher J. PeBenito wrote:
> On 09/15/11 08:16, Guido Trentalancia wrote:
> > Hi Christopher !
> > 
> > Thanks for the idea.
> > 
> > On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
> >> On 09/14/11 16:21, Eric Paris wrote:
> >>> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> >>>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> >>>>> At the moment we create a symlink:
> >>>>>
> >>>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> >>>>>
> >>>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> >>>>> ../../.  Instead create a symlink from
> >>>>>
> >>>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> >>>>>
> >>>>> Thus it works no matter what values one might use for LIBDIR and
> >>>>> SHLIBDIR.
> >>>>
> >>>> I'm not sure this works the way you would want.  Consider rpm build of
> >>>> libselinux - it does:
> >>>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> >>>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> >>>>
> >>>> And then rpm collects up the files into the package.
> >>>> But if the symlink encodes the full pathname used at make install time,
> >>>> then it will be wrong on the final system when the rpm is installed.
> >>>> Haven't actually tested that theory, but I think it is true.  Welcome to
> >>>> hell.
> >>>
> >>> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> >>> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> >>>
> >>> GRRRRRR.   Every other package I see with similar symlinks seems to be
> >>> an autoconf package and I can't understand how they work.  What we have
> >>> isn't right, but I don't know how to fix it....
> >>
> >> Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like
> >>
> >> install foo $(BINDIR)
> >>
> >> it turns into
> >>
> >> install foo $(DESTDIR)(BINDIR)
> >>
> >> Then when you have your symlink you can do
> >>
> >> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so
> > 
> > Yes, this is even better, although $(DESTDIR) is not necessary in the
> > target, as SHLIBDIR already includes (begins with) DESTDIR:
> > 
> > ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)
> 
> I think you're missing the point.  I said you need to stop specifying $(DESTDIR) as part of $(SHLIBDIR).  Otherwise you get the broken symlinks that Eric talks about above.

In any case, I think it then probably ends up taking more characters
than using pushd/popd.

Guido


--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Christopher J. PeBenito]

On 09/15/11 08:53, Guido Trentalancia wrote:
> On Thu, 2011-09-15 at 08:22 -0400, Christopher J. PeBenito wrote:
>> On 09/15/11 08:16, Guido Trentalancia wrote:
>>> On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
>>>> On 09/14/11 16:21, Eric Paris wrote:
>>>>> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
>>>>>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
>>>>>>> At the moment we create a symlink:
>>>>>>>
>>>>>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
>>>>>>>
>>>>>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
>>>>>>> ../../.  Instead create a symlink from
>>>>>>>
>>>>>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
>>>>>>>
>>>>>>> Thus it works no matter what values one might use for LIBDIR and
>>>>>>> SHLIBDIR.
>>>>>>
>>>>>> I'm not sure this works the way you would want.  Consider rpm build of
>>>>>> libselinux - it does:
>>>>>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
>>>>>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
>>>>>>
>>>>>> And then rpm collects up the files into the package.
>>>>>> But if the symlink encodes the full pathname used at make install time,
>>>>>> then it will be wrong on the final system when the rpm is installed.
>>>>>> Haven't actually tested that theory, but I think it is true.  Welcome to
>>>>>> hell.
>>>>>
>>>>> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
>>>>> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
>>>>>
>>>>> GRRRRRR.   Every other package I see with similar symlinks seems to be
>>>>> an autoconf package and I can't understand how they work.  What we have
>>>>> isn't right, but I don't know how to fix it....
>>>>
>>>> Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like
>>>>
>>>> install foo $(BINDIR)
>>>>
>>>> it turns into
>>>>
>>>> install foo $(DESTDIR)(BINDIR)
>>>>
>>>> Then when you have your symlink you can do
>>>>
>>>> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so
>>>
>>> Yes, this is even better, although $(DESTDIR) is not necessary in the
>>> target, as SHLIBDIR already includes (begins with) DESTDIR:
>>>
>>> ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)
>>
>> I think you're missing the point.  I said you need to stop specifying $(DESTDIR) as part of $(SHLIBDIR).  Otherwise you get the broken symlinks that Eric talks about above.
> 
> In any case, I think it then probably ends up taking more characters
> than using pushd/popd.

Perhaps it does.  I'd argue that its much clearer, thus more maintainable than pushd/popd.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Guido Trentalancia]

On Thu, 2011-09-15 at 13:01 -0400, Christopher J. PeBenito wrote:
> On 09/15/11 08:53, Guido Trentalancia wrote:
> > On Thu, 2011-09-15 at 08:22 -0400, Christopher J. PeBenito wrote:
> >> On 09/15/11 08:16, Guido Trentalancia wrote:
> >>> On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
> >>>> On 09/14/11 16:21, Eric Paris wrote:
> >>>>> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> >>>>>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> >>>>>>> At the moment we create a symlink:
> >>>>>>>
> >>>>>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> >>>>>>>
> >>>>>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> >>>>>>> ../../.  Instead create a symlink from
> >>>>>>>
> >>>>>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> >>>>>>>
> >>>>>>> Thus it works no matter what values one might use for LIBDIR and
> >>>>>>> SHLIBDIR.
> >>>>>>
> >>>>>> I'm not sure this works the way you would want.  Consider rpm build of
> >>>>>> libselinux - it does:
> >>>>>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> >>>>>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> >>>>>>
> >>>>>> And then rpm collects up the files into the package.
> >>>>>> But if the symlink encodes the full pathname used at make install time,
> >>>>>> then it will be wrong on the final system when the rpm is installed.
> >>>>>> Haven't actually tested that theory, but I think it is true.  Welcome to
> >>>>>> hell.
> >>>>>
> >>>>> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> >>>>> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> >>>>>
> >>>>> GRRRRRR.   Every other package I see with similar symlinks seems to be
> >>>>> an autoconf package and I can't understand how they work.  What we have
> >>>>> isn't right, but I don't know how to fix it....
> >>>>
> >>>> Its easy.  The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables.  Then when you use those variables, you prepend DESTDIR as necessary.  So if you have usages like
> >>>>
> >>>> install foo $(BINDIR)
> >>>>
> >>>> it turns into
> >>>>
> >>>> install foo $(DESTDIR)(BINDIR)
> >>>>
> >>>> Then when you have your symlink you can do
> >>>>
> >>>> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so
> >>>
> >>> Yes, this is even better, although $(DESTDIR) is not necessary in the
> >>> target, as SHLIBDIR already includes (begins with) DESTDIR:
> >>>
> >>> ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)
> >>
> >> I think you're missing the point.  I said you need to stop specifying $(DESTDIR) as part of $(SHLIBDIR).  Otherwise you get the broken symlinks that Eric talks about above.
> > 
> > In any case, I think it then probably ends up taking more characters
> > than using pushd/popd.
> 
> Perhaps it does.  I'd argue that its much clearer, thus more maintainable than pushd/popd.

Go on then.

echo "pushd \$(LIBDIR) ; popdpushd \$(SHLIBDIR) ; popd" | wc -m
47

What's the alternative ?

Guido


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

[PATCH] policycoreutils: fix sandbox Makefile

[Stephen Smalley]

Fix sandbox Makefile so that make DESTDIR=~/out install works again.

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

---

 policycoreutils/sandbox/Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/policycoreutils/sandbox/Makefile b/policycoreutils/sandbox/Makefile
index 21df0c4..4566810 100644
--- a/policycoreutils/sandbox/Makefile
+++ b/policycoreutils/sandbox/Makefile
@@ -2,6 +2,7 @@
 PREFIX ?= ${DESTDIR}/usr
 INITDIR ?= ${DESTDIR}/etc/rc.d/init.d/
 SYSCONFDIR ?= ${DESTDIR}/etc/sysconfig
+LIBDIR ?= $(PREFIX)/lib
 BINDIR ?= $(PREFIX)/bin
 SBINDIR ?= $(PREFIX)/sbin
 MANDIR ?= $(PREFIX)/share/man
@@ -13,7 +14,7 @@ LDLIBS += -lselinux -lcap-ng
 all: sandbox seunshare sandboxX.sh start
 
 seunshare: seunshare.o $(EXTRA_OBJS)
-	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
+	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) -L$(LIBDIR)
 
 install: all
 	-mkdir -p $(BINDIR)



-- 
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 2/2] libselinux: do not use relative path when creating libselinux symlinks

[Stephen Smalley]

On Wed, 2011-09-14 at 16:21 -0400, Eric Paris wrote:
> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> > On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> > > At the moment we create a symlink:
> > > 
> > > /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> > > 
> > > This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> > > ../../.  Instead create a symlink from
> > > 
> > > $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> > > 
> > > Thus it works no matter what values one might use for LIBDIR and
> > > SHLIBDIR.
> > 
> > I'm not sure this works the way you would want.  Consider rpm build of
> > libselinux - it does:
> > make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> > SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> > 
> > And then rpm collects up the files into the package.
> > But if the symlink encodes the full pathname used at make install time,
> > then it will be wrong on the final system when the rpm is installed.
> > Haven't actually tested that theory, but I think it is true.  Welcome to
> > hell.
> 
> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> 
> GRRRRRR.   Every other package I see with similar symlinks seems to be
> an autoconf package and I can't understand how they work.  What we have
> isn't right, but I don't know how to fix it....

Do we really need to change this?  While it is making an assumption
about LIBDIR and SHLIBDIR relative location, when is that assumption
false?  We certainly haven't had any complaints about it from any of the
distros.

-- 
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] policycoreutils: fix sandbox Makefile

[Guido Trentalancia]

On Thu, 2011-09-15 at 13:13 -0400, Stephen Smalley wrote:
> Fix sandbox Makefile so that make DESTDIR=~/out install works again.
> 
> Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
> 
> ---
> 
>  policycoreutils/sandbox/Makefile |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/policycoreutils/sandbox/Makefile b/policycoreutils/sandbox/Makefile
> index 21df0c4..4566810 100644
> --- a/policycoreutils/sandbox/Makefile
> +++ b/policycoreutils/sandbox/Makefile
> @@ -2,6 +2,7 @@
>  PREFIX ?= ${DESTDIR}/usr
>  INITDIR ?= ${DESTDIR}/etc/rc.d/init.d/
>  SYSCONFDIR ?= ${DESTDIR}/etc/sysconfig
> +LIBDIR ?= $(PREFIX)/lib
>  BINDIR ?= $(PREFIX)/bin
>  SBINDIR ?= $(PREFIX)/sbin
>  MANDIR ?= $(PREFIX)/share/man
> @@ -13,7 +14,7 @@ LDLIBS += -lselinux -lcap-ng
>  all: sandbox seunshare sandboxX.sh start
>  
>  seunshare: seunshare.o $(EXTRA_OBJS)
> -	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
> +	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) -L$(LIBDIR)

EXTRA_OBJS is not defined therefore it is empty unless passed from the
command-line...

Perhaps you meant the -L flag goes before the LDLIBS (which is made just
of -l flags) ?

as in: 

-	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
+	$(CC) $(LDFLAGS) -o $@ $^ -L$(LIBDIR) $(LDLIBS)

>  install: all
>  	-mkdir -p $(BINDIR)
> 

Guido


--
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] policycoreutils: fix sandbox Makefile

[Stephen Smalley]

On Thu, 2011-09-15 at 19:38 +0200, Guido Trentalancia wrote:
> On Thu, 2011-09-15 at 13:13 -0400, Stephen Smalley wrote:
> > Fix sandbox Makefile so that make DESTDIR=~/out install works again.
> > 
> > Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
> > 
> > ---
> > 
> >  policycoreutils/sandbox/Makefile |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/policycoreutils/sandbox/Makefile b/policycoreutils/sandbox/Makefile
> > index 21df0c4..4566810 100644
> > --- a/policycoreutils/sandbox/Makefile
> > +++ b/policycoreutils/sandbox/Makefile
> > @@ -2,6 +2,7 @@
> >  PREFIX ?= ${DESTDIR}/usr
> >  INITDIR ?= ${DESTDIR}/etc/rc.d/init.d/
> >  SYSCONFDIR ?= ${DESTDIR}/etc/sysconfig
> > +LIBDIR ?= $(PREFIX)/lib
> >  BINDIR ?= $(PREFIX)/bin
> >  SBINDIR ?= $(PREFIX)/sbin
> >  MANDIR ?= $(PREFIX)/share/man
> > @@ -13,7 +14,7 @@ LDLIBS += -lselinux -lcap-ng
> >  all: sandbox seunshare sandboxX.sh start
> >  
> >  seunshare: seunshare.o $(EXTRA_OBJS)
> > -	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
> > +	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) -L$(LIBDIR)
> 
> EXTRA_OBJS is not defined therefore it is empty unless passed from the
> command-line...

I didn't introduce or modify the use of EXTRA_OBJS; that isn't affected
by my patch.

> Perhaps you meant the -L flag goes before the LDLIBS (which is made just
> of -l flags) ?
> 
> as in: 
> 
> -	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
> +	$(CC) $(LDFLAGS) -o $@ $^ -L$(LIBDIR) $(LDLIBS)

It doesn't matter.  Per man ld:
 "All -L options apply to all -l options, regardless of the order in
which the options appear."

And my patch does fix the problem.

-- 
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] policycoreutils: fix sandbox Makefile

[Guido Trentalancia]

On Thu, 2011-09-15 at 13:50 -0400, Stephen Smalley wrote:
> On Thu, 2011-09-15 at 19:38 +0200, Guido Trentalancia wrote:
> > On Thu, 2011-09-15 at 13:13 -0400, Stephen Smalley wrote:
> > > Fix sandbox Makefile so that make DESTDIR=~/out install works again.
> > > 
> > > Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
> > > 
> > > ---
> > > 
> > >  policycoreutils/sandbox/Makefile |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/policycoreutils/sandbox/Makefile b/policycoreutils/sandbox/Makefile
> > > index 21df0c4..4566810 100644
> > > --- a/policycoreutils/sandbox/Makefile
> > > +++ b/policycoreutils/sandbox/Makefile
> > > @@ -2,6 +2,7 @@
> > >  PREFIX ?= ${DESTDIR}/usr
> > >  INITDIR ?= ${DESTDIR}/etc/rc.d/init.d/
> > >  SYSCONFDIR ?= ${DESTDIR}/etc/sysconfig
> > > +LIBDIR ?= $(PREFIX)/lib
> > >  BINDIR ?= $(PREFIX)/bin
> > >  SBINDIR ?= $(PREFIX)/sbin
> > >  MANDIR ?= $(PREFIX)/share/man
> > > @@ -13,7 +14,7 @@ LDLIBS += -lselinux -lcap-ng
> > >  all: sandbox seunshare sandboxX.sh start
> > >  
> > >  seunshare: seunshare.o $(EXTRA_OBJS)
> > > -	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
> > > +	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) -L$(LIBDIR)
> > 
> > EXTRA_OBJS is not defined therefore it is empty unless passed from the
> > command-line...
> 
> I didn't introduce or modify the use of EXTRA_OBJS; that isn't affected
> by my patch.

So what sort of problem were you getting exactly ? I never experienced
any problem with that. It is also being done elsewhere I suppose...

> > Perhaps you meant the -L flag goes before the LDLIBS (which is made just
> > of -l flags) ?
> > 
> > as in: 
> > 
> > -	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
> > +	$(CC) $(LDFLAGS) -o $@ $^ -L$(LIBDIR) $(LDLIBS)
> 
> It doesn't matter.  Per man ld:
>  "All -L options apply to all -l options, regardless of the order in
> which the options appear."

You are right.

> And my patch does fix the problem.

I am still missing the problem I think. Or perhaps it's just that on my
system it stops much earlier when not using the patch that I have
created...

Guido


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