Re: password file locking

[Jim Dennis <jimd linuxcare com>]

Apparently Cooper <Cooper@Linuxfan.com>  wrote:
 
> Okay, alternative approach.
 
> Open+lock passwd, read passwd, update data, write passwd.new, rename
> passwd.new to passwd, close locked passwd.

 Here's some (ugly) psuedo-code:

	     if open(...O_EXCL) (lockfile)
		open pwfile (RO)
		read/verify pw
		open newpw (WR)
		update/copy (old to new) --- this is a filtering operation
		close newpw
		close pwfile
		mv pwfile to pw.old
		mv newpw to pwfile
		(build new hash tables if nsswitch.conf has db enable?)
		(push these out if they are NIS/NIS+ maps or ???)
	    else
		open lock file
		read PID
		check process status of PID
		if (not it's alive)
		   remove stale lockfile
		   continue (go back to top)
		else
		   ???
		
 
> The trick here is that you can't wait for the passwd file to become
> available to you because once the lock is cleared, the file the lock was
> on nolonger exists, so you'll have to resort to polling.
> Since the passwd and shadow files don't get updated all that much by
> multiple sources at the same time it might be a workable solution, but I
> might just be (wrongly) assuming a small site with the initial
> assumption about the amount of updates.
 
> Cooper

 What locking API are you using?

 It seems like the suite of password/group file update utilities
 ({user,group}{add,mod,del} and chfn, passwd, et al) could use 
 UUCP style lock files (files under /var/lock/shadow/ containing 
 the PID of the process which currently holds a lock).

 However, I still wonder what a process should do when it has
 failed to get the lock?

 I've wondered about this before.  When we try to get a lock
 (using UNIX local file semantics) and we fail, how do we know
 when to retry.  I wonder if it makes sense for programs participating
 in locking to open the file (read-only) and do a select() (or poll()?) 
 on it.

 This would require that the process holding the lock append something
 to it prior to removing it.  That would effectively notify all 
 waiting processes to wake up and compete for the new lock.

 Does that make sense?  Do any of the existing program suites using
 lock files implement this mechanism?  It still seems more efficient 
 than polling. 

 (Note: I'm not a programmer, and I don't play one on the net.
 I just do a bit of scripting here and there).

--
Jim Dennis         Technical Research Analyst            Linuxcare, Inc.
             jimd@linuxcare.com, http://www.linuxcare.com/
             415 505-9306                415 701-7457 fax
                 Linuxcare: Support for the Revolution