GNOME Bugzilla – Bug 474219
--with-pam-dir does nothing
Last modified: 2019-02-22 11:47:33 UTC
currently --with-pam-dir does nothing, make install && make install-pam still wants to install pam_gnome_keyring.so to /usr/lib I am no autotools-guru, but the problem seems to be the usage of $(DESTDIR)$(libdir). changeing to $(DESTDIR)$(PAM_DEST_DIR) seems to fix it. It installs pam_gnome_keyring.so to the right place and /usr/lib if --with-pam-dir is not set. Patch attached.
Created attachment 95053 [details] [review] changes $(DESTDIR)$(libdir) to $(DESTDIR)$(PAM_DEST_DIR)
Could you make your edits to Makefile.am? That would help give me a clearer picture of what's changing.
I do not know what changes to Makefile.am I am supposed to do as no changes to Makefile.am corrects the behavior...
...on the other hand I do not know how autotools works, so I do not know if there is something you can add to correct the behavior.
Ok, after som alcoholic and a lot off good music (its funny how much can happend in just one hour) I took a look at Makefile.am and I think adding libdir = "$(PAM_DEST_DIR)" to pam/makefile.am seems to make things more working. Should maybe test whats happends with a unset --with-pam-dir also.... ....and that seemd to work. So I propose: --- gnome-keyring-2.19.91.old/pam/Makefile.am 2007-09-06 18:55:32.000000000 +0200 +++ gnome-keyring-2.19.91/pam/Makefile.am 2007-09-06 19:52:55.000000000 +0200 @@ -4,6 +4,7 @@ -DGNOME_KEYRING_DAEMON=\""$(bindir)/gnome-keyring-daemon"\" lib_LTLIBRARIES = pam_gnome_keyring.la +libdir = "$(PAM_DEST_DIR)" pam_gnome_keyring_la_SOURCES = \ gkr-pam.h \ But remeber I am drunk so you maybe have to really test it some more.
Which OS and version of gnome-keyring is this? Could you post the output of 'make install' and 'make install-pam' (without your patch)?
Created attachment 95213 [details] logfile for make install ./configure --prefix=/home/xake/Desktop/keyring/temp --enable-pam --with-pam-dir=/home/xake/Desktop/keyring/temp/lib/sec
Created attachment 95214 [details] logfile for make install-pam As you can see it tries to install to prefix/lib instead of the --with-pam-dir destination.
I see this line, it looks like it is installing it to your --with-pam-dir directory: cp "/home/xake/Desktop/keyring/temp/lib/pam_gnome_keyring.so" "/home/xake/Desktop/keyring/temp/lib/sec" Note that it *also* installs it to $prefix/lib (to placate autotools).
Why does it need make install-pam and does not get installed by default when you have --enable-pam? Is there not any better way to make autotools happy? This feels like a ugly hack to me.
There may be a better way, but (in true autotools fashion) I haven't been able to the voodoo required. Note that 'make distcheck' is what fails, since it wants everything to be installed in one subdirectory.
Created attachment 96557 [details] [review] fix --with-pam-dir Simpler patch for configure.in and pam/Makefile.am NB, I've changed the default PAM_DEST_DIR to /lib/security because it's the default for all pam packages out there. Feel free to change it back though :)
Created attachment 96561 [details] [review] fix --with-pam-dir Same patch, but this one removes the creation of the symlinks. Everything leads me to believe they are not needed (but I have yet to try hooking pam to gnome keyring) One of our users is probably going to try it before me, I'll let you know how it works for him. As for `make distcheck`, it fails for me with this error : gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -Werror -g -O2 -Wno-strict-aliasing -Wno-sign-compare -MT unit-test-cleanup.o -MD -MP -MF .deps/unit-test-cleanup.Tpo -c -o unit-test-cleanup.o unit-test-cleanup.c cc1: warnings being treated as errors unit-test-cleanup.c: In function ‘cleanup_callback’: unit-test-cleanup.c:56: warning: comparison with string literal results in unspecified behaviour make[2]: *** [unit-test-cleanup.o] Error 1 make[2]: Leaving directory `/home/remi/c++/gnome-keyring/tests' This is probably not related at all to pam :)
This patch breaks 'make distcheck', which is the reason for this whole convoluted two step install/install-pam. If you have an idea or fix which passes 'make distcheck' then it's very welcome.
I had the same error before and after applying the patch. The exact same error as in comment #12. Could you at least tell me how it breaks on your box? I am not at all familiar with gnome-keyring's codebase and I have _no_ idea why the unit tests are breaking. Are we actually seeing the same errors?
@Stef: Have you acctually tested Remis patch? For me it passes distcheck just as easy as without. @Remi: I think something is wrong in your system, using a Gentoo stable (Gnome 2.18) and do './configure --enable-pam --with-pam-dir=/lib/security --prefix=/usr --enable-tests --enable-gtk-doc --enable-debug --enable-maintainer-mode && make && make dist && make distcheck' did pass for me both with applied patch and without (I had to do sudo make distcheck with the patch becouse it wanted to write to /lib/security, which failed becouse of permissons).
If you'd use user writable directory as prefixes, make install and make distcheck would probably pass this permission problem. Giving root access to make distcheck could hide other problems.
Doing 'make distcheck' without write-permission in /lib/security is a no-can-do since 'make distcheck' plays with /lib/security anyway since that is the default in configure nad thus give permission-errors. However: the error Stef is talking about should fail even IF you run it as root, right? Since he talks about a check that fails if 'make install' want to install things outside of a specific subdir, and even given write permission this test would fail.
I did forgot to say that 'make install' does want to install everything according to options given to configure, it is just 'make distcheck' who still wants to play with '/lib/security'.
Sorry for the bugspam but I just wanted to say that changeing the hardcoded default (i.e. /lib/security) in the patch to something user-writable and 'make distcheck' passes without root-privs. The command given: './configure --prefix=/home/xake/Desktop/gnome-temp/install/usr --enable-pam --with-pam-dir=/home/xake/Desktop/gnome-temp/install/lib --enable-gtk-doc --enable-debug --enable-tests --enable-maintainer-mode && make && make distcheck' (the --with-pam-dir variable is the same that I hardcoded its default to)
Created attachment 96617 [details] [review] fix --with-pam-dir and `make distcheck` This patch adds ${prefix} to the default pam-dir. This fixes `make distcheck`, but forces people installing gnome-keyring to specify --with-pam-dir=/lib/security if they want to use pam. (Otherwise, pam-dir will default to /usr/local/lib/security) From our (Gentoo's) point of view, this doesn't matter as we will always specify --with-pam-dir in our scripts (we're not big fans of automagical stuff ;)) Maybe this could be mentioned in the release notes for other distros to pick up? I sincerely hope this patch satisfies everyone's expectations. Cheers.
The error in comment #13 is just (some version of) GCC being dumb. But I've committed a fix to work around the warning.
The patch looks good. I've committed and added some warnings under the 'install-pam' make target. Updated instructions here: http://live.gnome.org/GnomeKeyring/Pam I'm hoping this doesn't break distro's packaging. I checked out the FC RPM spec file and it doesn't look like it would. For the record distcheck was failing when not running as root (which is how it should always be run).
The 2.20.1 update has no pam_gnome_keyring_auth.so and pam_gnome_keyring_session.so, is that expected? That seems to be due to this change.
That is becouse those files are symlinks to "pam_gnome_keyring.so" which are produced when you do 'make install-pam' for gnome-keyring-2.20.0. When in gnome-keyring-2.20.1 the placement of pam_gnome_keyring.so was moved to 'make install' the creating of those symlinks was somehow removed/skipped. Anyone up for some automake-magic?
I've tried with and without the symlinks, and I can't get it to work ... *grumble* I've tried following the doc on the wiki, but it still doesn't unlock. If anyone has a working setup, I'll gladly test it to make sure it works with and without the symlinks. As a side note, I've skimmed through the PAM documentation [1] and the gnome-keyring code, and I've found no reference whatsoever to *_session and *_auth symlinks or module names. I'd be interested in knowing why they were ever needed in the first place. [1] http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
I can't either. It seems like it unlocks 'login' very good. But then it fails to unlock 'default' for me. It asks every time if it should automatically, but a relogin later it asks again...
Ok, I've finally gotten it to work, it unlocks the 'login' keyring and everything works from there. I can confirm that those symlinks are indeed useless (also confirmed by our resident PAM guru in Gentoo).