I know that wasn't your question, but I'd like to warn you that it's pretty weird to have a CGI script manipulating /etc/passwd directly. This means that the CGI must have how to read this file (that's quite regular) and worse, the CGI script will have how to *write* to /etc/passwd. This means that:
IMHO, this is absolutelly unacceptable, as one single failure in your script can exploit the entire system in a single act. The correct way of doing that, IMHO, is using the Unix PAM to change the password. This way you'll have how to say that your script, after authenticated with something (which can be any implemented PAM module), has the right to change the password for a *set of users*. Then PAM (something more people trust on) will change the passwords even if they aren't in /etc/passwd, which makes your CGI more portable...
UPDATE: Reading better, I saw you just wanted to lock for reading, which is much safer, as you don't need to write on it after all.
UPDATE 2: I was just thinking... why aren't you using getpwent() instead of reading /etc/passwd? This way you won't need to care about NIS, LDAP or such... and won't need to care about locking, as glibc will return a reasonable value...
In reply to Re: How to make sure that non-Perl programs will respect Perl's file locking?
by ruoso
in thread How to make sure that non-Perl programs will respect Perl's file locking?
by glasswalk3r
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |