Re: How to make sure that non-Perl programs will respect Perl's file locking?

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:

You have your /etc/passwd writeable for others that root
Your script is running as root (gah)

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

daniel

Comment on Re: How to make sure that non-Perl programs will respect Perl's file locking?

Replies are listed 'Best First'.
Re^2: How to make sure that non-Perl programs will respect Perl's file locking? by glasswalk3r (Friar) on Jan 11, 2006 at 18:16 UTC
That is an interesting point. But I'm not using neither of your options: the CGI uses the program Sudo (and a tight setup of it) to get the proper rights. Using Taint mode also helps regarding security breachs. The UNIX PAM recomendation is a good one but is not that portable: Slackware Linux, for example, doesn't use PAM AFAIK. Besides doing this helps to solve only part of the problem: the CGI still needs to update the smbpasswd file without anybody else doing it at the same time. Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply]
Re^3: How to make sure that non-Perl programs will respect Perl's file locking? by ruoso (Curate) on Jan 11, 2006 at 18:25 UTC
Hmmm... So you do are changing the smbpasswd in your CGI script... I wouldn't recommend it... The fact that Slackware doesn't support PAM is really a suprise to me... I've been using PAM for a long time and actually can't think how it can't be in Slackware... Anyway... If you were using PAM, you could place a pam module that reflects the changes on the user password to the smbpasswd file. (I know such module exists, just don't remeber its name). "Fixing" your Slackware to include PAM is possibly a good idea, or else you'll have to stick with this insecure approuch of changing this files directly... daniel	[reply]
Re^4: How to make sure that non-Perl programs will respect Perl's file locking? by lRem (Scribe) on Jan 11, 2006 at 21:12 UTC
It never was in Slackware, as well as it never was in OpenBSD. And in the latter, it probably never will, with no way to install it by yourself. As for me, this is enough to don't use PAM in my programs. Unless I would think it's worth implementing both PAM and PAMless versions (which I never did). On the other hand, PAM can be added to Slackware and all other Linux distros. So when you're not thinking about OpenBSD (other UN*Xes have PAM support), you can just add PAM to the dependencies list. -- Someday, people who know how to use computers will rule over those who don't. And there will be a special name for them: secretaries. -Dilbert quote	[reply]