[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM and shadow

> Wichert,
> use pam_pwdb (which uses a little helper binary to check the user's own
> password).  This is how Redhat's xlock is not setuid root and yet works
> with shadow passwords.
> Alternatively, you could modify the helper binary to be of use with
> pam_unix.. (shouldn't be too hard).
> Cheers
> Andrew

	How?  What is the name of the "little helper binary" and
	how does one call it from within one's own code?

	I certainly hope you aren't suggesting that Wichert
	creates *another* little helper binary.  Let's make 
	*one* "little helper binary" that can be SUID (preferably 
	mode 4550 --- and make any programs that are supposed
	to use it SGID to the appropriate group).  Then admins
	only have to audit and allow *one* SUID file for all 
	the 'vlock', 'screen', 'xlock' and 'lockvc' programs
	in the world.

	(Actually I'd be even happier if the /etc/shadow files
	was group readable --- and the various utilities that 
	needed to authenticate against it were SGID/shadow.
	I'd also like to see the getpwent() call automatically
	merge shadow entries with account information anytime
	the /etc/shadow file is readable.  This is similar to the
	FreeBSD method --- but it wouldn't require that the
	authenticating programs run as 'root'  Then even programs
	that weren't PAM or even "shadow" aware would be able 
	to authenticate.  --- Yes, all of the appropriate nss_
	modules would have to also have this sort of "merge if
	you can" logic.)

	So, Andrew --- about your new years resolution: Are 
	we going to see a few more releases this year --- maybe
	even approach 1.x.  Are we going to get OPIE and/or S/Key
	(TM) "out of the box" so we can discourage the scourge of
	reusable passwords over insecure links?

> Wichert Akkerman wrote:

>> I was looking at modifying lockvc to use PAM the other day. lockvc is a
>> terminal locking program that uses svgalib to show some nice graphics.
>> Like all svgalib programs it drops it root priviledges after
>> initializing the graphic system. As a result when a user tries to unlock
>> his system lockvc no longer can read /etc/shadow and PAM gives an error.

>> The standard solution I use is to open /etc/shadow before dropping the
>> root priviledges and later use fgetpwent() to get the shadow passwords.
>> I looked at the PAM sources to see if I could make a PAM module which
>> does that, but I found that apparently there is no method for a module
>> to be initialized when pam_start() is called.

>> Is there any solution to this problem, besides adding an initialization
>> function to the pam_module (hope I remembered the name correctly) struct?

>> Wichert.

Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []