Just a thought, but since I know RH7.2 includes the PAM (pluggable authentication module) system, you may want to take a look at Authen::PAM, a perl interface into the PAM. Just a thought... HTH.

Thanks for the tip. I knew there was something called "PAM" that I needed to look for, but my initial searches yielded nothing, so I assumed I must have been starting with bad info. Thanks for the link.

Authen::PAM won't help with shadow passwords. Root is the only user that can read /etc/shadow, so root is the only user that can verify password.

The advantage of using PAM is that it handles all the mechanisms for authenticating users. It takes care of the encryption algorithms: crypt, MD5, etc. It also will handle users authenticated through LDAP, Samba, NIS, or something else.

1. Indeed. On Linux, you will only get the (encrypted) password if you run your program with root permissions, as that's the only UID that can read /etc/shadow.
2. 'perldoc -f crypt' has an example.

Abigail

#!/usr/bin/perl

$U="ronzo";
$P=q/"[test]"/;

print "P=$P  \n";
$P=~s/\\/\\\\\\\\/g;    # escape the \ for shell
$P=~s/"/\\"/g;          # escape the " for shell
$P=~s/'/\\'/g;          # escape the ' for shell
$P=~s/`/\\`/g;          # escape the ` for shell
$P=~s/!/\\!/g;          # escape the ! for shell

print "P=", $P,   " \n";

#run  ftp command with ``
my $a=`(ftp -n -v - <<EOF
open  localhost
user $U $P
bye
EOF
) 2>&1`;

# a good connect will return a 230 User X Logged In
if ($a =~ /230 /) {
     print "Password Good  \n";
} else {
     print "Password BAD  \n";
}
[download]

It's not the best, but I tested it and it works, even with the funny character passwords. Just gotta get all the shell characters escaped if you run into any bad passwords that can't verify properly. Since I grew up on shell scripting I still rely on it for solutions.

On the FTP, -n does not auto login
-v for verbose, so it returns the 230 message.
- just the minus, for using STDIN for FTP commands
At the end of the FTP is the 2>&1, this just redirects STDERR back to STDOUT, this way $a has all the output.

I've used this method in the past, and you don't have to deal with having read access to /etc/shadow or special permissions to run other programs that can read the shadow file. The Apache user can do this just fine.

ronzo

I've used this method in the past, and you don't have to deal with having read access to /etc/shadow or special permissions to run other programs that can read the shadow file.

Well, you do run another program with special permissions, and it's called 'ftpd'. Not something I recommend to solve this problem.

The Apache user can do this just fine.

On a properly configured system, there's only one user that can read /etc/shadow, and that's UID 0, aka root. Unless you change the permissions of /etc/shadow, or give the apache user UID 0 (neither of those action is smart), it ain't going to work.

Abigail

Apache is generally started as root (it needs to be root to bind to a low port, port 80) and changes its effective UID at the earliest opportunity.

I don't think you you quite understand what I suggested. If you already have FTP enabled (and on 7.2 thats default) why not use it for authenication.

Well, you do run another program with special permissions, and it's called 'ftpd'. Not something I recommend to solve this problem.

So we should all turn off FTP on our servers?
Your not running ftpd with some special permissions, your actually attempting to login to ftp localhost.

I'm not saying this is the best method, but it is a perfectly acceptable solution for the Linux world where scripts and other programs are the building blocks for you to use.

ronzo

Good info. I guess that reconfiguring suexec so that it can act as user 0 would open up too many potential doors, wouldn't it?

Excellent. I actually started to try this method when I couldn't find "PAM", but I thought I wouldn't want to re-invent the wheel if there was a more elegant solution. If the authen::pam stuff doesn't work out, I'm using your code!!