libselinux: put libselinux.so.1 in /lib not /usr/lib
PATCH 1/2 libselinux: put libselinux.so.1 in /lib not /usr/lib
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.
--- libselinux/src/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
libselinux/src/Makefile +1 -1
@@ -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))
Signature · 7 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
PATCH 2/2 libselinux: do not use relative path when creating libselinux symlinks
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.
--- libselinux/src/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
libselinux/src/Makefile +1 -1
@@ -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
Signature · 7 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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.
Quoted 19 lines
Signed-off-by Eric Paris <[email protected]>--- libselinux/src/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)libselinux/src/Makefile +1
-1@@ -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
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.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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
Quoted 5 lines
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 [email protected] 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,
please see my patch.
You fix it like this:
libselinux/src/Makefile +1 -1
@@ -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:
libsemanage/src/Makefile +1 -1
@@ -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
libsepol/src/Makefile +1 -1
@@ -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
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.
Quoted 9 lines
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.1GRRRRRR. 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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
In reply to Eric ParisQuoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.
Quoted 6 lines
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.1GRRRRRR. 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
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Hi Christopher !
Thanks for the idea.
Quoted 37 lines · Christopher J. PeBenito
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.Quoted 6 lines
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.1GRRRRRR. 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)
Quoted 7 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 46 lines · Guido Trentalancia
Hi Christopher !
Thanks for the idea.
Quoted 41 lines · Christopher J. PeBenito
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.Quoted 6 lines
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.1GRRRRRR. 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)
Quoted 8 lines
Quoted 3 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 49 lines · Christopher J. PeBenito
Quoted 48 lines · Guido Trentalancia
Hi Christopher !
Thanks for the idea.
Quoted 43 lines · Christopher J. PeBenito
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.Quoted 6 lines
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.1GRRRRRR. 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
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
In reply to Christopher J. PeBenitoQuoted 49 lines · Christopher J. PeBenito
Quoted 48 lines · Guido Trentalancia
Hi Christopher !
Thanks for the idea.
Quoted 43 lines · Christopher J. PeBenito
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.Quoted 6 lines
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.1GRRRRRR. 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
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 51 lines · Guido Trentalancia
Quoted 50 lines · Christopher J. PeBenito
Quoted 49 lines · Guido Trentalancia
Quoted 37 lines · Christopher J. PeBenito
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.Quoted 6 lines
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.1GRRRRRR. 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)
Quoted 7 lines
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:
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 52 lines · Christopher J. PeBenito
Quoted 51 lines · Guido Trentalancia
Quoted 50 lines · Christopher J. PeBenito
Quoted 49 lines · Guido Trentalancia
Quoted 37 lines · Christopher J. PeBenito
Quoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.Quoted 6 lines
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.1GRRRRRR. 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)
Quoted 7 lines
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:
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
In reply to Eric ParisQuoted 25 lines · Eric Paris
Quoted 18 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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}" installQuoted 5 lines
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.
Quoted 6 lines
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.1GRRRRRR. 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.
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.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
In reply to Stephen SmalleyQuoted 13 lines · Stephen Smalley
Quoted 11 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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.
Quoted 6 lines
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}" installAnd 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).
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 17 lines
Quoted 17 lines
Signed-off-by Eric Paris <[email protected]>--- libselinux/src/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)libselinux/src/Makefile +1
-1@@ -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)
Quoted 3 lines
libselinux/src/Makefile install: all · line 132
Quoted 2 lines
libselinux/src/Makefile +0
-0install-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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
In reply to Eric ParisHi Eric.
Quoted 6 lines · Eric Paris
At the moment we create a symlink:
/usr/lib/libselinux.so-> ../../lib/libselinux.so.1This 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.
Quoted 4 lines
$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.
Quoted 10 lines
Signed-off-by Eric Paris <[email protected]>--- libselinux/src/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)libselinux/src/Makefile +0
-0
libselinux/src/Makefile install: all · line 132
Quoted 8 lines
libselinux/src/Makefile +1
-1@@ -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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 7 lines · Guido Trentalancia
Quoted 4 lines
$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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH 2/2] libselinux: do not use relative path when creating libselinux symlinks
Quoted 10 lines · Eric Paris
Quoted 7 lines · Guido Trentalancia
Quoted 4 lines
$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.
Quoted 8 lines
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/lib64altogether. 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).
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.
Quoted 5 lines · Eric Paris
Commit
874bac80bbfbf0a5incorrectly 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 <[email protected]>
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
PATCH 1/1 policycoreutils: fix sandbox Makefile
Fix sandbox Makefile so that make DESTDIR=~/out install works again.
---
policycoreutils/sandbox/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
policycoreutils/sandbox/Makefile +2 -1
@@ -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)
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.
Re: [PATCH] policycoreutils: fix sandbox Makefile
Quoted 22 lines · Stephen Smalley
Fix sandbox
Makefileso that make DESTDIR=~/out install works again.Signed-off-by Stephen Smalley <[email protected]>---
policycoreutils/sandbox/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)policycoreutils/sandbox/Makefile +1
-0@@ -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
policycoreutils/sandbox/Makefile LDLIBS += -lselinux -lcap-ng · line 17
Quoted 5 lines
policycoreutils/sandbox/Makefile +1
-1@@ -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)
policycoreutils/sandbox/Makefile LDLIBS += -lselinux -lcap-ng
Quoted 3 lines
policycoreutils/sandbox/Makefile +0
-0install: 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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Re: [PATCH] policycoreutils: fix sandbox Makefile
Quoted 25 lines · Guido Trentalancia
Quoted 24 lines · Stephen Smalley
Fix sandbox
Makefileso that make DESTDIR=~/out install works again.Signed-off-by Stephen Smalley <[email protected]>---
policycoreutils/sandbox/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)policycoreutils/sandbox/Makefile +1
-0@@ -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
Quoted 6 lines
policycoreutils/sandbox/Makefile LDLIBS += -lselinux -lcap-ng · line 17
Quoted 3 lines
policycoreutils/sandbox/Makefile +1
-1seunshare: seunshare.o $(EXTRA_OBJS) - $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) + $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) -L$(LIBDIR)
EXTRA_OBJSis 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.
Review
Quoted 7 lines
Perhaps you meant the -L flag goes before the LDLIBS (which is made just of -l flags) ?
as in:
(quoted diff) +1
-1- $(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.
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.
Re: [PATCH] policycoreutils: fix sandbox Makefile
Quoted 33 lines · Stephen Smalley
Quoted 25 lines · Guido Trentalancia
Quoted 24 lines · Stephen Smalley
Fix sandbox
Makefileso that make DESTDIR=~/out install works again.Signed-off-by Stephen Smalley <[email protected]>---
policycoreutils/sandbox/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)policycoreutils/sandbox/Makefile +1
-0@@ -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 startQuoted 6 lines
policycoreutils/sandbox/Makefile LDLIBS += -lselinux -lcap-ng · line 17
Quoted 3 lines
policycoreutils/sandbox/Makefile +1
-1seunshare: seunshare.o $(EXTRA_OBJS) - $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) + $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) -L$(LIBDIR)
EXTRA_OBJSis not defined therefore it is empty unless passed from the command-line...
Quoted 2 lines
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...
Quoted 11 lines
Review
Quoted 7 lines
Perhaps you meant the -L flag goes before the LDLIBS (which is made just of -l flags) ?
as in:
(quoted diff) +1
-1- $(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.
Quoted 1 line
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.