Writing into Keyboard buffer in AIX

[muthursyamburi]

Hello All,

I'm really looking for a help in reading/writing the keyboard buffer in AIX (IBM Unix). In DOS, there is some memory addres (I remember it as 0x417) from where the keyboard buffer starts. But I need the same in AIX.

My requirement is this. In AIX, we need to change the password every 60 days or so. And while changing, it wont accept the previous 4 passwords we used. But when you change to a new one, its difficult to remember the current pwd everytime. (You may say to write it some where. But thats clumsy!!).

Suppose my pwd is "welcome". When it expires, I will change it to a new pwd, say passwd1. Then I will change the same 3 more times with some junk pwds and the fourth time, I will give the old pwd itself (ie, "welcome").

In AIX, we can change the password using "passwd", but here the issue is that, it wont accept the password as a parameter and will be waiting for us to enter it through keyboard. Also, please note that I'm a normal user and not the "root".

Thats when I planned to go for mutli-threading where in one thread, I will be running the "passwd" program and when it waits for the pwd, through another thread I will provide the password. There comes the requirement of writing into the keyboard buffer directly...

Any body knows about this, please help me... :(

T&R
Muthursyamburi

[RRick]

From what I can tell, you want to use the passwd program to change the user's password without any user intervention. That's fine.

Passwd is expecting info on stdin, and one way to fix the problem is to redirect passwd's stdin. From a script,

##  Input from a file
passwd < newStuff.txt
 
## Input from File Descriptor 5 (I think)
passwd <5
 

This can be done programmaticall y, via fork and exec calls, but I don't have the details.

There are some programs that check to see if stdin is from a terminal, and won't let you redirect a file to it. In that case, you can directly access the input buffer, but this is based on what Unix calls tty. Try "man -k tty" for more details.

[muthursyamburi]

From what I can tell, you want to use the passwd program to change the user's password without any user intervention. That's fine.

Passwd is expecting info on stdin, and one way to fix the problem is to redirect passwd's stdin. From a script,

##  Input from a file
passwd < newStuff.txt
 
## Input from File Descriptor 5 (I think)
passwd <5
 

This can be done programmaticall y, via fork and exec calls, but I don't have the details.

There are some programs that check to see if stdin is from a terminal, and won't let you redirect a file to it. In that case, you can directly access the input buffer, but this is based on what Unix calls tty. Try "man -k tty" for more details.

Hi,

Thanks for understanding my requirement exactly and giving me a prompt reply. However, I tried both the ways but in vain... :(.

1) I tried to redirect a file containing pwds to that it didn't work.
2) I wrote one c program which, using fork() & execvp(), will call a shell in another thread in which I will be running the "passwd". Then through the c program I tried sending the pwds thru message pipes and in the shell program I redirected it from the pipe (I used the file descriptor 3) to the passwd. That also didn't worked out...

After a lot of search in the web, I could get one function called "g32_send_keys( )" (see this: g32_send_keys ) but the associated header files (g32_api.h & g32_keys.h) is not there in my system and thus that also didn't work out... :((

T&R
Muthursyamburi

[RRick]

I took a look at the man info for passwd on my Linux box. Since you are not root, you will be able only change your account's password. You can't change anyone else's passwd.

On linux, there is a --stdin option that allows information to be received from, you guessed it, stdin. Unfortunately, you must be root to use this. From everything I've seen, this looks like the best solution.

Finally, I'm not sure you will be able to trick passwd with the keybuffer tricks. There are ways to tell if the program is being run interactively, and no amount of keyboard games is going to fix this.

Sorry for the negative post, but good luck.