[gentoo-amd64] Re: Problems with pam-0.99 upgrade

[Duncan]

Richard Freeman <rich@××××××××××××××.net> posted
472DB4C5.60100@××××××××××××××.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@g.o mailing list