Submitting password changes to external program

[Dietz]

Fellow Monks!

I'm working on this for over 2 days now to no avail, and I must admit IPC is one of my weakest fields. I have got the task to automate resetting passwords without user input on AIX /w HACMP. Although I'm allowed to test as root user, I'm not allowed to install any modules like Expect.

When I run the external command over the command line, I type in the passwords which get not displayed and all is OK:

# /usr/es/sbin/cluster/sbin/cl_chpasswd -cspoc -f -k testuser
Changing password for "testuser"
testuser's New password: 
Enter the new password again:
# echo $?
0
#

When run by my test script and hitting <Ctrl+C> after the second password display:

# ./test.pl
testuser's New password: testpass
testpass

3004-657 Terminating from signal.

# echo $?
130
#

When run by my test script and typing in the password followed by <ENTER> after second password display:

# ./test.pl
testuser's New password: testpass
testpass

Enter the new password again:
# echo $?
0
#

So I can see the passwords get printed but the external program doesn't get the input.
Any ideas?
Thanks in advance!
Below my test script:

#!/usr/bin/perl
use strict;
use warnings;
$ENV{ODMDIR} = '/etc/objrepos/'; # needed for external program
my $user = 'testuser';
my $password = 'testpass';
my $cmd = "/usr/es/sbin/cluster/sbin/cl_chpasswd -cspoc -f -k $user";
#print $cmd, $/x2; # verified - OK

use IPC::Open2;
my $pid = open2(*Reader, *Writer, $cmd);

# No success with following variations:
#my $pid = open2(*Reader, *Writer, "$cmd </dev/tty");
#my $pid = open2(*Reader, *Writer, "$cmd </dev/tty >/dev/tty");
$| = 1;

# Verify device:
#use POSIX;
#my $tty = POSIX::ctermid();
#print "\nTTY: '$tty'\n\n"; # prints: TTY: '/dev/tty'

local *STDOUT;
open( STDOUT, ">>/dev/tty" );

# wait until external program is ready
sleep 5; 

# Enter password:
#print Writer "$password\n"; # neither displayed nor accepted as input
print "$password\n"; # will be displayed but not accepted as input
sleep 2;

# Repeat password:
#print Writer "$password\n";
print "$password\n";

waitpid $pid, 0;
close Reader;
close Writer;

[Fletch]

Programs like passwd tend to re-open /dev/tty themselves to read from rather than using STDIN. You need to use something like Expect to run it on its own pty instead.

[Dietz]

Does this mean that /dev/tty gets re-opened by passwd and such programs after I redirect STDOUT to /dev/tty?

[Fletch]

Yes, passwd ignores its STDIN and opens /dev/tty to read the password from.

[gri6507]

Perhaps this is a good job for PAR. You can develop on a machine where you can install any module you like (such as Expect) and then PAR your program up into an executable which then gets delivered to your host machine. This would mean that you don't need to install anything on the destination machines, yet still reap the benefits of all desired modules.

[Dietz]

Sounds like a good idea, never done anything with PAR so far, will definitely look into, though I wished there was a simpler IPC solution.

[mikeraz]

Why interact with the system tools at all? Why not just collect the new PW, encrypt it, and write directly to /etc/shadow? (Or write direct to /etc/passwd if AIX still stores passwords there.) That would seem to be a more direct and simple way to work.

[Celada]

Because the system tools are the published API!

Using the system tools will allow the software to work unchanged if the passwd database backend is not flat files. Perhaps more importantly in the case that you do not expect to be using anything other than flat files as the backend, the system tools will respect all the conventions regarding updates to /etc/passwd and /etc/shadow like making a backup file after changes (/etc/opasswd, maybe), file locking, and use of MD5 passwords versus traditional crypt, all of which you might not know about and which may vary from system to system.

Using a pty is a pain, but it's worth it.