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

Re: password file locking

Michael Tokarev wrote:
> But wait -- one big issue with this exists.  Note that
> "dotlock" file created before opening real /etc/passwd file,
> and it does _not_ removed after use. But applications that
> updates /etc/passwd need to have reliable way to change
> contents of that file, that is typically implemented by
> creating new file and issuing two rename()s.

I feel I'm starting to lose track here, so am I right in assuming you
rename passwd to something else (passwd.old) and then the new thing to
the new passwd?

> With this,
> it is hard to ensure that second app that waits for a lock
> will use correct /etc/passwd when first lock released, not
> a file that was renamed by first app.

Correct. Which I think is exactly why you shouldn't use a second file
when you try to lock a file. When you rename a new file to the current
name, anybody who has the current file open will basically be using old
data once the rename is complete. If that old data was used as a
starting point for a modification the fun can begin.

> With this, "dotlock" method is far more reliable when
> locking of /etc/passwd itself (recall -- dotlock _never_
> removed).  Method used by util-linux (?) (creating
> passwd.lck and shadow.lck) is less reliable, but
> lckpwdf()'s one (creating /etc/.pwd.lock) is a best.

I totally fail to see the apparently obvious advantage of having a lock
file with a different name.

When using a lock on the file itself, you're in the clear unless you
want to replace the file in question with a different file. Since a file
needs to be opened *BEFORE* you can acquire a POSIX lock, you need to
stick to that one file which can be considered a disadvantage.

If you want to add to the passwd file the POSIX lock will do. You lock,
append, if that fails ftruncate back to the old size and it seems as if
nothing happened.
If you want to delete from the passwd file, you could use a POSIX lock.
You lock, read, delete the line from the read data, write the data back
to the file starting at filepos 0 and truncate whatever space is left.
Problems arise when you want to update a line. It can be done with a
POSIX lock too, but is more complicated. You lock, read, take out but
locally store the line, write the remainder starting at pos 0, update
the locally stored line in another location, write that at the current
position of the file and if that were to fail you truncate back to that
position and write the old line instead.

This approach will work as long as nobody pulls the plug on the machine
during the writes, which is really the only drawback of this approach.
If that were to happen (enter Mr. Murphy) the potential is that lines
get clobbered and that is, particularly with these files, totally
To counter this the update and delete could simply blank out the line in
the file and in the case of an update simply append to the end of the
file. This will make a mess of the passwd file though.

Bottom line, considering all this above (hope you'll excuse my
think-as-I-type message) POSIX locks alone seem inadequate for this

Still curious to see how the "dotlock" file thing solves the problem...
Best I can tell it moves the problem to the lockfile, but doesn't remove

If you can read this you're probably not dead yet.
	- Johnny The Homicidal Maniac 7 -

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