Okay this is not news, but seems like it’s still a problem for someone, so I’m following fox2mike’s suggestion (from yesterday.. I initially forgot about doing so), and I’m blogging about it…
So many people using ~arch or some packages out of ~arch might have seen that a new update to shadow (>=4.0.12-r2) blocks pam-login, and pam-login blocks newer versions of shadow.
Why this? Well it’s simple to say for me, as I know the background, but might be less easy to understand without knowing that.
So let’s start with the reason why /bin/login was not provided by shadow when using pam (thing that happens on most desktop systems)… to be honest, I don’t know that for sure, probably it’s just that shadow weren’t providing a PAM-enabled /bin/login or it had problems in the past.. so we just gone using pam-login package from SuSE (in the good days when people _provided_ the tarballs for other distributions to use), the 3.x series.
This was all good until shadow 4.0.something started providing a valid /bin/login, so we just had pam-login ebuild to build /bin/login from shadow source code.. but that meant we had to build the same code two times, and maintain patches for two packages instead of one.
So as this was planned for a while but Azarah hasn’t had time to handle that, I decided to do the merge between the two: since shadow 4.0.14-r2 the single sys-apps/shadow package replaces both shadow AND the old pam-login package. This means that they block each other now, so you have to do something like:
emerge -C pam-login && emerge -u shadow
if you want to have your system working fine. If you just unmerge pam-login but NOT update shadow, you won’t be able to login in the system if you restart (although already running sessions, already waiting login prompts, xdm and variants and ssh won’t be affected).
Please also note that you need a recent version of util-linux, that dropped the pam useflag, if you want to be sure that it won’t request you to merge pam-login again; ~arch version is fine. For older versions you might want to just set util-linux to use -pam with package.use as it doesn’t change anything anyway.
Now, don’t start asking for better way to handle this, as portage does not provide anything to improve this. This works without strange surprises, so just drop pam-login and you’ll be fine 
Update: Comments have been closed because this post had too much spam coming. If you want to say yours, use the repost. Thanks, Diego.
It seems to me that you never will want both PAM-login and shadow-login so why not just unmerge PAM in the ebuild scripts whenever shadow is to be updated? I can’t see what could possibly break.
Famous last words. With suitible warnings and messages, of course. These messages will scroll by while you’re asleep after saying emerge –update world. Very useful when you are looking through the logs after something doesn’t work any more.
Martins
It might also be worth taking the opportunity to say that the average user doesn’t really need PAM support anyway. Correct me if I’m wrong but I’ve been running this system without PAM for months and everything’s been fine.
Unmerging from an ebuild isn’t viable. The block will disallow you from running a blind emerge -uD world without first taking care of the issue..
And about PAM need… many things lately rely on the use of PAM, to set limits and other things, so I wouldn’t say it’s unneeded.. it can be avoided, but I wouldn’t do that anyway.
Ok. So wath can I do if I unmerged pam-login and restarted my system. Now I am unable to startx by user and gdm won’t start to.
I guess the same you would do whenever the system gets too borked to be fixed alone.
Fire up a gentoo live cd, mount the partitions, make the chroot and emerge shadow. Just like when you installed gentoo, except this time you only install one package instead of ‘emerge system’ and whatnot.
No, the reason we used pam-login rather than shadow’s login was a very very nasty root exploit. ( three tries to login as root, where the third time you entered a blank password and you got a root shell …. *Cough* ) In that timeframe we were a bit annoyed and dubious on the security of the login implementation in shadow, so we went with pam instead. ( there were a lot of other pam issues back then as well, but this one is the most significant )
Ok, gents, somewhat of a newb here – I unmerged pam-login, but haven’t logged out of that session (lucky).
I ran the emerge string above: [emerge -C pam-login && emerge -u shadow] with these results:
localhost ~ # emerge -C pam-login && emerge -u shadow
— Couldn’t find pam-login to unmerge.
>>> No packages selected for removal by unmerge.
Calculating dependencies… done!
>>> Auto-cleaning packages…
>>> No outdated packages were found on your system.
* GNU info directory index is up-to-date.
Next, I looked through the emerge.log file and found the original version I unmerged: pam-login-3.17
I tried: emerge -uDpv pam-login-3.17
with the following result:
These are the packages that would be merged, in order:
Calculating dependencies
!!! ‘pam-login-3.17′ is not a valid package atom.
!!! Please check ebuild(5) for full details.
!!! (Did you specify a version but forget to prefix with ‘=’?)
Not sure what to do next – is there something other than chrooting to fix? Will chroot and re-emerging pam-login work?
Thanks…cd
I can’t figure out what to do next. BTW, I’m ok with pam-login – seems like more and more apps are utilizing it.
Thanks for the info, Diego — most helpful.
So, if you _do_ remove pam-login but the system goes down before shadow gets updated (no, this is not a joke, bad luck can happen), and now you _cannot_ login, what do you do ? If I boot with init=/bin/sh I can’t even change root password because of some authorization token lock errors. And I’m pretty sure I won’t be able to update shadow when booting from a live cd, since the system installed is an ~amd64 with another kernel.
if you are unlucky enough to unmerge pam-login and have your computer freeze while emerging world, there is hope. you may be able to login through ssh (assuming you have sshd running, and another computer). i’m nearly finished emerging shadow right now after a ten minute panic when login wasn’t working.
I suggest this:
FEATURES=-collision-protect emerge –nodeps shadow && emerge –unmerge pam-login
That way you never lose /bin/login at any point in time.
Thanks verry much diego
NOTE:If you can’t emerge -u shadow, because you already have the latest version etc., then unmerge it and try again. (Directed at the newb guy)
I did exactly like in the post. I’m going to reboot the system and login from SSH. I guess that if I go to the datacenter, i can login from there without problems.
I’m gonna kill some of you guys if the update to the server doesn’t go smooth.
I love Portage.
what if i want pam over shadow, ie: i’m running a server where applications/services will be relying upon pam. i tried reversing the original instructions, and rebooted fine but still get pam blocked by shadow when i do an emerge -Dup world.
best,
joe
Please read the entry, it is not _pam_ being blocked, but pam-login, and the only reason is that shadow with pam useflag IS pam-login.
so should i remove pam from my useflag? if i emerged the shadow package and unmerged the pam thing?
I’ve successfully dealt with this issue on my own systems by simply unmerging shadow and remerging it, because it’s blocking on itself for me (I use the ‘pam’ USE flag). I didn’t have to unmerge pam-login or change any USE flags this way.
YMMV
Thank you for posting this. This was a problem for me, and now it is solved.
Daniel Lin
Thank you, you are very useful.
Thanks for this, Diego. I hadn’t sync’ed for weeks: 167 packages to update, and this stopping them! Now it’s fixed. You da man!
Thanks. Most illuminating.