Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
When building freeradius I ran into the following problem: when building the rlm_unix dynamic module (trace follows) it tries to link with -lshadow, there is no libshadow.so (i'll get into that a bit later.) so libtool will make that a "-Wl,--whole-archive /usr/lib/libshadow.a -Wl,--no-whole-archive" sequence. rlm_unix is dynamic, but libshadow.a IS NOT compiled with -fPIC therefore the following errors are logged: ---8<--- /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol wipe_clear_pass /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol clear_pass /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol wipe_clear_pass /usr/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.3.2/../../../../alphaev56-unknown-linux-gnu/bin/ld: /usr/lib/libshadow.a(pwauth.o): gp-relative relocation against dynamic symbol clear_pass ---8<--- hinting that libshadow.a should be compiled with -fPIC. If a libshadow.so were existent all would have gone well, as -dynamic modeles get built with -fPIC. Trying to build shadow-4.0.3-r9 it shows it DOES NOT BUILD .so libraries it even says in the release notes they are deleted. Building it will show that dynamic building fails because of a missing -lpam -lpam_misc library during linking. The problem seems to be related to the makefile, the LIBS= assignment is empty if that assignment is LIB="-lpam -lpam_misc" then linking works. This does prevent freeradius from being built.
Nico, what do you mean by "it even says in the release notes they are deleted"?
Thanks Nico, this is fixed in shadow-4.0.3-r10
I found some references to it in the NEWS file within the package... shadow-980626 => shadow-980724 - security: login no longer gives you a root shell if setgid() or initgroups() or setuid() fails for any reason, discovered by Ted Hickman <thickman@sy.net> - remove libshadow.so -> libshadow.so.x.x symlink after install - a few int -> uid_t type cleanups - fail immediately (don't retry) in *_lock() if euid != 0 - added sample PAM config files etc/pam.d/{passwd,su} - preliminary PAM support in su (untested - use at your own risk, comments and patches welcome!) - cleanup and more comments in OPIE code (Algis Rudys) - added support for TCFS (Transparent Cryptographic File System) (use ./configure --with-libtcfs, see http://tcfs.dia.unisa.it/ for more info), thanks to Aniello Del Sorbo ... I'll test the package when it arrives...
It compiled without troubles for me now, i'll use parts of it in the coming week to verify it still works... ;-)
reviewing the shado build the following struck me.... everything except /bin/su & /bin/groups are in /usr/bin or /usr/sbin... the libraries are in /usr/lib this means that su & groups won't work when /usr isn't mounted! (they also use libcrypt & libcrack ) maybe the libshadow.so and libmisc.so need to be on the /lib directory..? or su and groups can move to /usr/bin? groups is in the /usr/bin directory on redhat. su is in /bin there. Redhat doesn't use the crypt & crack libraries in the shadow-utils. Also pam isn't used there....
Azarah, would you mind commenting on this? I see the following comment in the Makefile.am: # XXX why are login and su in /bin anyway (other than for # historical reasons)? # # if the system is screwed so badly that it can't mount /usr, # you can (hopefully) boot single user, and then you're root # so you don't need these programs for recovery. # # also /lib/libshadow.so.x.xx (if any) could be moved to /usr/lib # and installation would be much simpler (just two directories, # $prefix/bin and $prefix/sbin, no install-data hacks...) It seems to me that we have three options, and I would like you to tell me which one would be best in your opinion (Az): 1. Move /bin/su, /bin/login and /bin/groups to /usr/bin based on the Makefile.am comment above. This means that libshadow.so and libmisc.so could stay in /usr/lib 2. Move /usr/lib/libshadow.so and /usr/lib/libmisc.so to /lib 3. Revert the ebuild to --disable-shared so that only libmisc.a and libshadow.a are built, but add -fPIC to the ebuild so that shared objects can link against these archives. Do you see any other options? What is your opinion? Presently -r9 builds only the static libs, and that is the stable version. -r10 builds the shared objs and installs them in /usr/lib, and is the ~arch version.
Either way I do not have an issue. I think there was issues with shared libshadow (anyone tried a bootstrap && emerge system with -r10 yet?), but I wont swear by it. You might run into issues with / bloat fanatics if you move the libs to /lib. If you however decide on .so's in /lib, please look at gen_usr_ldscript() in eutils.eclass ... BTW, does both pam 0.76 and 0.77 build with the shared libs?
Btw, /bin/login is hardcoded into agetty, so either we need another symlink, or the /lib/*.so is the best bet.
Or -fPIC I guess. It will be the smallest one (no extra files/libs/symlinks) ...
Az, I think the first thing I'll try is option 1 in comment 6. That's moving the binaries to /usr/bin. It's the most likely option to have problems, but on the other hand, if it works then we have removed three binaries from the root partition. I'll look into fixing agetty to use /usr/bin/login (and search for other programs/scripts that would need to be fixed). In order for this to happen, I'll package.mask -r10 for now and I'll test a bootstrap.
Re comment #10 login belongs in /bin please don't try to move it to /usr/bin
I go for -fPIC then. Aron, is it Ok to just add 'add-flags -fPIC' to the ebuild, or do you guys do it another way?
AFAICT, /bin/login doesn't use libshadow.so so that is not an issue for this one...
It will if you remerge pam with the shared libshadow around ...
fixed in shadow-4.0.4.1-r1 by adding -fPIC
Okay, I'll bite. But just because noone else does (even though they were going to more than a year ago..) <extra_quiet> THAT'S WRONG WRONG WRONG! </extra_quiet> libshadow, as well as libmisc, are internal to the shadow package and are not supposed to be in /usr/lib. In linux, shadow support is in libc5, well, ever since there are shadow passwords in linux, and in glibc2 forever. Just look what other distributions are doing. Why do you want to punish all the innocent shadow binaries with -fPIC? Way too cruel for my taste! BAM!
on 64 bit (risk-)architectures a lot of the code/data is only reached when base pointers to datastructures are used. That is because there is no place to store 64bit pointers inside an instruction (for risk at most 32bits wide) For static programs of fairly small sizes this is an academic issue. On 32 bit architectures that can reference memory directly from an struction the same... In my case freeradius is dynamicaly linked and it uses the shadow libraries to verify passwords. Because the shadow libraries were not -fPIC compiled they were preventing freeradius from building on 64bit architectures. Thats why sometimes -fPIC IS needed... As far as I'm concerned freeradius now build with the current options. Thanks.
Yes, that'd all be correct if freeradius really needed to link to libshadow; in that case it would be wrong to link non-pic objects into a shared lib on ALL arches. And it's still wrong to link pic objects into executables on ALL arches. BUT; what gentoo maintainers seem to forget is: (1) freeradius does NOT NEED libshadow. (2) libshadow and libmisc are internal libs to the shadow suite and should NOT EXIST in /usr/lib. It's just another example of 'If something unrelated breaks, -fPIC will cure it.' So let's start a little quiz: 1. What header file declares types and functions exported from libshadow? The shadow ebuild certainly does not install any headers. 2. Name the .deb, .tgz, or .rpm that provides libshadow.a in Deb/Slac/SuSE. 3. What function(s) does freeradius (really) need from libshadow? (4. I'll ask this Q later because it would give away the answers to 1.-3.)
Hans, I appreciate the expertise you bring to the table. Regarding shadow and freeradius, neither one is my area of expertise, I'm just helping out in an area that needs the help. If you want to provide some help, that's quite appreciated, but you might consider offering patches instead of quizzes. I'll re-open this bug in anticipation of your follow-up.
functions reference in the link errors are: 1) I didn't study libshadow and it's surroundings, just tried to get freeradius working. (a mail is underway on freeradius about this...) 2) No idea, don't use debian,Suse,Slacware I used to run Redhat 9 but that was announce to be scrapped about now, so I converted to something else..... here comes Gentoo 3) And the nominees are: - wipe_clear_pass - clear_pass as used in the rlm_unix module. Couldn't find a reference to those in glibc
appearantly the whole discussion is moot now, the rlm_unix module can link without -lshadow.... The make file still names the library though
easy to explain: src/modules/rlm_unix first checks for getspnam in libc: AC_CHECK_FUNCS(getspnam getusershell) checking for getspnam... yes checking for getusershell... yes next test is getspnam in libshadow: AC_CHECK_LIB(shadow, getspnam, [ unix_ldflags="${unix_ldflags} -lshadow" AC_DEFINE(HAVE_GETSPNAM) ] ) checking for getspnam in -lshadow... (result doesn't matter at this pt.) whether the test succeeds or not; doesn't matter; the first test already has found getspnam in libc and add HAVE_GETSPNAM in config.h; no effect on the generated code; only difference is: libshadow !found: nothing libshadow found: append -lshadow to ldflags probably because whoever wrote these tests did not expect shadow functions in more than one place. ^L Best fix that does not need modifications to other packages is simply to not install libshadow. Quoting from shadow-4.0.3/doc/README.linux: "Currently, libshadow.a is for internal use only, so if you see -lshadow in a Makefile of some other package, it is safe to remove it." But such Makefiles are rare, most configure scripts never put -lshadow in Makefiles if there is no libshadow. ___Debian___ simply skips libshadow and libmisc when moving files to their individual sub-packages. ___SuSE___ does this: ./configure [...] --disable-shared [...] make install DESTDIR=$RPM_BUILD_ROOT rm $RPM_BUILD_ROOT/lib/lib{misc,shadow}.{a,la} Slackware and RedHat may be doing the same or something completely different, but with the same result. so how about this::: --------8<--------8<--------8<--------8<--------8<--------8<--------8<-------- --- shadow-4.0.3/lib/Makefile.am~ Sat Oct 6 21:53:20 2001 +++ shadow-4.0.3/lib/Makefile.am Wed May 12 19:33:52 2004 @@ -4,7 +4,7 @@ DEFS = INCLUDES = -I$(top_srcdir) -lib_LTLIBRARIES = libshadow.la +noinst_LTLIBRARIES = libshadow.la libshadow_la_LDFLAGS = -version-info 0:0:0 libshadow_la_LIBADD = $(INTLLIBS) $(LIBCRYPT) $(LIBTCFS) $(LIBSKEY) $(LIBMD) \ --- shadow-4.0.3/libmisc/Makefile.am~ Sun Mar 10 08:11:55 2002 +++ shadow-4.0.3/libmisc/Makefile.am Wed May 12 19:34:43 2004 @@ -5,7 +5,7 @@ INCLUDES = -I$(top_srcdir) -I$(top_srcdir)/lib -lib_LTLIBRARIES = libmisc.la +noinst_LTLIBRARIES = libmisc.la libmisc_la_SOURCES = \ addgrps.c \ -------->8-------->8-------->8-------->8-------->8-------->8-------->8-------- ???
Hans, I still haven't forgotten this... just back from vacation and digging into bugs :-)
Thanks Hans! I used the Suse approach and removed the libraries instead of patching Makefile.am. That way I don't need to add an autoconf dep to the shadow package for now. Finally fixed. Please let me know if you spot something I did wrong.
