From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IofUY-0005bB-08 for garchives@archives.gentoo.org; Sun, 04 Nov 2007 13:26:18 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id lA4DOSdO026529; Sun, 4 Nov 2007 13:24:28 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id lA4DORk4026521 for ; Sun, 4 Nov 2007 13:24:27 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IofSN-0002Dt-3W for gentoo-amd64@lists.gentoo.org; Sun, 04 Nov 2007 13:24:03 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2007 13:24:03 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2007 13:24:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Problems with pam-0.99 upgrade Date: Sun, 4 Nov 2007 13:23:49 +0000 (UTC) Message-ID: References: <5bdc1c8b0711031648q4eca5ab8t46a77c6e29884e12@mail.gmail.com> <472DB4C5.60100@thefreemanclan.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news X-Archives-Salt: f65d853e-fef0-4bc2-837c-8274e07f7c42 X-Archives-Hash: 4aa3667d51b8d6630f9a978475ee0c68 Richard Freeman posted 472DB4C5.60100@thefreemanclan.net, excerpted below, on Sun, 04 Nov 2007 07:02:13 -0500: > Mark Knecht wrote: >> OK, knowing as you all do that I'm a non-admin sort of person these >> sort of instructions - the >> 2 paragraphs at the end - scare me. I hate having to guess what anyone >> means. >> >> lightning pam.d # qfile -o /etc/pam.d/* /etc/pam.d/gdmconfig >> /etc/pam.d/xdm >> lightning pam.d # >> >> > I was having the same problems earlier in the week. The solution is > actually pretty simple. The output above indicates that xdm and > gdmconfig aren't being used any longer - they're orphans. I just moved > the files elsewhere (for temporary safe-keeping), and upgraded PAM, and > there were no issues. All the files that used the obsolete functions > were upgraded some time ago apparently - but if you have a system that > has been upgraded year-after-year apparently there are orphan files that > date WAY back... > > However, I agree that PAM is one of those things that everybody depends > on but otherwise seems to behave like black magic for most people. I've > yet to see a guide on PAM that actually makes it easy to understand. Agreed with getting the stale files out of the way... remember where you put them in case you need them, and setup a reminder if you like, to delete them in a month or so if nothing goes wrong. That's a pretty generic one-size-fits-all solution for "mystery files". =8^) The idea with pam_stack.so is to remove from your active config anything that mentions it. So after removing any stale files, search/grep/ whatever the dir for anything else containing pam_stack.so. Those are the files and lines that must be changed, because pam_stack.so no longer exists after the upgrade. As for pam_console.so, let's illustrate what it does with an example, we'll say the sound devices. On Gentoo by default they are set accessible by the audio group. Now consider an office machine used by a number of folks in the office, all who have users in the audio group. Say someone's working at the machine, and his co-worker decides to play a prank. Logging in remotely from another machine, since he's in the audio group, he turns up the volume and plays a nice juicy fart sound! Obviously that could be rather embarrassing! =8^) That is of course an amusing example, but there are more security oriented ones as well. What pam_console does is provide a way to dynamically control permissions for various system devices based on who is actually logged on at the console. It's specific user permissions rather than general group permissions, but they are effective only when the user is logged in. Unfortunately, pam_console seriously "complexifies" administration, because now instead of having to worry about permissions in one or two spots (udev config and perhaps device specific settings elsewhere), there's a third spot as well, and what's even worse, the dynamic behavior makes it harder to troubleshoot. Worst of all, depending on login method, some sessions, particularly X sessions, aren't considered console sessions at all. Thus, it's possible for a user to be sitting at the machine and actively working in X, but not be considered "logged in" at the console, in which case all those permissions pam_console is supposed to grant won't apply, and the user (and admin) are often left trying to figure out why the user doesn't have the permissions udev and etc say he SHOULD have! So while pam_console has its place on a system used by many separate user logins, Gentoo devs eventually got tired of tracking down the related permissions issues and decided it was better to have pam_console as a separate package and disabled by default. "And Gentoo users and admins everywhere danced with joy!" =8^) So that's the story behind pam_console -- you were right, it /should/ be left commented, unless you want to seriously "complexify" your administrative duties. =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list