Cooper wrote:
>
> Okay, alternative approach.
>
> Open+lock passwd, read passwd, update data, write passwd.new, rename
> passwd.new to passwd, close locked passwd.
>
> 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.
Exactly (but I doesn't understand what "polling" means here). We should
do stat/fstat to compare what we have opened and what we have in
real /etc/passwd, and repeat this if them are differ.
This can be achieved almost without any problems/races. I just
not shure that all applications that will use this approach will
implement it (not difficult, but anyway not-so-trivial) right.
lckpwd() have _no_ races and it have very simple interface:
if (lckpwdf() == 0) {
do updates
unlckpwdf()
}
and that's all. :) Oh, I'm lazy... ;)))))))
> 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.
No, it is not about heavily updates. Conflicts are just less frequent
on "small sites", but them are _exists_ always (unless you only one
user of the system -- but even in this case you should take care of
that).
> Cooper
> --
> If you can read this you're probably not dead yet.
> - Johnny The Homicidal Maniac 7 -
