this is suse's pam_unix2. It has support for blowfish encrypted passwords.
*** Bug 97426 has been marked as a duplicate of this bug. ***
Created attachment 62281 [details] this is my ebuild
The DEPEND is just *ahem*... Why don't you use DEPEND="sys-libs/pam" libxcrypt? ( sys-libs/libxcrypt )" Also, only add such KEYWORDS for ARCHs that you actually tested.
I was already planning on adding it after sys-auth is in place. Will take a bit anyway.
flameeyes: bump
Created attachment 90287 [details] Version 1.30 of pam_unix2 Hope it could get into the official portage tree.(it would be very nice) This is version 1.30 of pam_unix2, the latest so far.
bumpity bump bump. I want it please???? *pouty face* :d
flameseyes: *bump*
Sorry forgot to update about this. Last time I tried, I wasn't able to actually get it to work, or rather, it was breaking login entirely, I tried to get it to work in a week, and then gave up. I admit I forgot what the actual problem was :/ Will try to check a newer version ASAP, but I wouldn't count on it.
Created attachment 101715 [details] new ebuild for version 2.1 I just got pam_unix2-2.1 to work on a bunch of workstations authenticating against a NIS server running SuSE linux. The source code needed a little bit of patching (see following attachment).
Created attachment 101716 [details, diff] patch to honor HAVE_PAM_PROMPT correctly This patch resolved the problem with 'unresolved external pam_prompt'. Without the patch, the vanilla sources compile fine but loading pam_unix2.so *WILL* fail.
FWIW, the ebuild works fantastically well - running happily on x86-hardened-2.6. For the uninitiated: - Make sure /etc/make.conf has a valid PORTDIR_OVERLAY and that the directory exists; I presume it's in /usr/local/portage mkdir -p -m755 /usr/local/portage/sys-libs/pam_unix2/files wget -O - http://bugs.gentoo.org/attachment.cgi?id=101715 >\ /usr/local/portage/pam_unix2/pam_unix2-2.1.ebuild wget -O - http://bugs.gentoo.org/attachment.cgi?id=101716 >\ /usr/local/portage/pam_unix2/files/pam_prompt-gentoo.patch # May have to edit KEYWORDS to include your ARCH ebuild /usr/local/portage/pam_unix2/pam_unix2-2.1.ebuild digest emerge pam_unix2 - Edit /etc/pam.d/system-auth and replace 'pam_unix.so' with 'pam_unix2.so'. There are some options (likeauth, shadow) that you should probably remove, as pam_unix2 doesn't understand them & will complain about them in your logs - if you don't understand what they are or how to deal with them, best just leave them in case you ever have to go back to pam_unix. - Edit /etc/default/passwd and set CRYPT to blowfish, and we're all done here. I'm all for incorporating this into the base system (read: default to BF hashes); anything good that improves security is fine by me. I just wish I had time to volunteer to maintain this.
I've been seeing issues this fall (new systems installed in September) where app-misc/screen won't unlock for a non-root user with pam_unix2 but does with pam_unix. The logs are about worthless, and strace doesn't seem to give me much more. Screen is the only app I have failing against PAM, but I suspect that's because it's the only one starting from non-root privileges. I've been halfheartedly poking at this thing for a while - anyone else have an idea?
I can reproduce failing pam login with pam_unix2 (blowfish, 10 rounds) with the apps app-misc/screen and x11-misc/alock (alock -auth pam) which both run with user rights. I found out that giving the user the rights to read /etc/shadow resolves this problem. Maybe that helps you.
I figured that out, but making /etc/shadow world readable (or readable by anyone other than root) is highly inadvisable, as that defeats the very purpose of shadow passwords. I would frankly rather not be able to use locking than go back to the security stone age. Where is EUID supposed to be set to 0 in the PAM chain, and why does it only fail for pam_unix2?
x11-misc/xscreensaver has the same problem. It even tells an error: "Permissions on the password database may be to restrictive." Sorry, but I don't know more details about pam.
So, I sacrificed my afternoon for the investigastions. The result is the following: In pam_unix (files pam_unix_passwd.c and support.c in modules/pam_unix) the following is done (support.c:_unix_verify_password) - First the module tries to get password from /etc/passwd resp. (if shadowed) /etc/shadow without changing uid. - If this fails, it calls support.c:_unix_run_helper_binary This function forks and calls /sbin/unix_chkpwd. This program has the suid modifier set. So it is able to read /etc/shadow.
Thorsten Kukuk, the maintainer of pam_unix2 from SuSE Linux wrote me: (translated) pam_unix2 works in SuSE Linux without problems, because in SuSE Linux applications stick to the PAM specification. This specification requires that applications using PAM have the necessary rights the access /etc/shadow.
Thanks for pursuing this farther - my German is so rudimentary I would have had to resort to the code to figure this out. Of course, that assumes Thorsten doesn't speak English, which I'm sure he probably does - flawlessly. :) At the moment, I still see this on a VT but not via SSH, so would have to agree this is not an issue with pam_unix2; it remains as quality as ever. I will pursue the issue with screen and see what I can find out. That still leaves us 'maintainerless' - I guess some dev has to specifically adopt orphan packages like this to guarantee updates and maintenance? I think it's an awfully low-maintenance app, given that many of us have been using the 2.1 ebuilds for over a year now.
Created attachment 154851 [details] ebuild for 2.5.0 2.5.0 came out last month, I made some minor modifications to the ebuild to reflect quoting feedback made to me and trim it down a little. Since 2.1, several translations have been added/fixed, changes have been made to remove use of newer symbols in libxcrypt, and other misc. bugfixes. Compiles and runs perfectly well.
Created attachment 166725 [details] 2.6 ebuild Updated to version 2.6, also added libxcrypt-3.0.2 and a dependency on >= version 3.0. This module now handles the new SHA hashes, has further updated translations, and improved logging (now logs host & tty).
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
I abandoned this module about the time I last posted, opting instead for the SHA support in the mainstream pam_unix module. Not precisely what I wanted, but more supportable. My opinion would be to close this WONTFIX and guide people still using the module to the SHA256/512 modes of pam_unix.
Is anyone still using this and would be interested in seeing it in sunrise?
Sunrise really shouldn't try to carry stuff like PAM moudles as they're likely to screw up main-tree system packages. Given that our default module already supports SHA512, and pambase integrates with that, the PAM team (aka me) vetoes for this to ever enter anything near something official of Gentoo.
(In reply to comment #25) > Sunrise really shouldn't try to carry stuff like PAM moudles as they're likely > to screw up main-tree system packages. > > Given that our default module already supports SHA512, and pambase integrates > with that, the PAM team (aka me) vetoes for this to ever enter anything near > something official of Gentoo. > No problem, sounds like a good policy decision to me. It's still here if anyone ever needs it... Got any free positions in QA? :)
