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

Re: password file locking



Cooper wrote:
> 
> "Michael Ju. Tokarev" wrote:
> > Well, I see two common locking mechanisms:
> >
> >   lckpwdf way is creating /etc/.pwd.lock file to lock
> >   both passwd and shadow
> >
> >   other way used in shadow-utils (if lckpwdf is not
> >   available?) and pwdb is to create passwd.lck and
> >   shadow.lck files
> 
> With either method you're basically saying that all files that deal with
> modifying the passwd and shadow files need to agree to check for the
> existance of the lock before doing anything.
> 
> Besides the fact that this approach can lead to obvious race issues, why
> not use POSIX 1 advisory locks (or 'discretionary file locks' as the
> fcntl man page calls them)?
>
> They're cross-platform and placed on the file itself so no race issues
> can exist as long as everybody plays ball. Since that's a requirement
> for both approaches I would think that this is a far better solution.

Maybe historic choice?  I don't know...
But note that method choosen to lock files MUST be the same for
all applications that uses that lock, or else we're in trouble.
lckpwdf() provided by some vendors (solaris, linux) tries to
solve this problem, so that all apps just use it.  How it implements
that locking is another question -- this can be fcntl(), flock(),
creating of lock file, semaphore etc.  Yes, easiest way seemed to
be to use fcntl or flock on file itself.

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.  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.
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.

> Cooper

Regards,
 Michael.





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