Thread: passwd - Unix

I am attempting to write a program that interfaces to the *nix passwd command. My intent is to keep it as portable as possible across different environments and eventually will need a Windows port. However, for now *nix is more than sufficient.

My understanding in reading the boards it that system() does not allow communication between child and parent processes. I would need the following steps:

1. Parent runs passwd as child.
2. child writes "Changing passwd for user.\n Old password:" and waits for input.
3. Parent sends the old password as supplied by the user.
4. child writes "New password:" and waits for input.
5. Parent sends the new password as supplied by the user.
6. child writes "Re-enter new password:" and waits for input.
7. Parent re-sends the new password as supplied by the user.
8 child exits successfully.

We have an ERP system which does not allow access to the underlying OS. Per recent regulations we need to implement password expiry and interfacing through a scripting language like Expect is not an option.

Jason

You will have to sue the passwd call in a here doc that you build dynamically, then call
fork() exec() (or system).

The problem with this is that it is not secure.

The real question: why must you execute passwd in a child process interactively like this?

You could simply

Code:

system("/usr/bin/passwd"); 
exit(EXIT_SUCCESS);

and not worry whether or not the passwd "took". By exiting you force the user to log back in again. I'm assuming you run users in a restricted shell.

Also see popen().

The real question: why must you execute passwd in a child process interactively like this?

The ERP system blocks all messages from the OS (In this case HP-UX) Therefore any direct calls to shell out are blocked. The only users who have access directly to the OS are the administrators and programmers.

If we were to turn on HP-UX's password expiry functionality, a user would never see the warning messages that their password is about to expire. This means that one day their login would fail and the helpdesk would be flooded with calls.

From my understanding system() is unsecure and could leave the OS open for exploitation.

You are correct, system() has security problems.

You could create a simple setuid program (another potential security problem)
that calls passwd via fork() and execl().

The problem, if I understand it, is that ERP completely shuts off all OS interaction. Does ERP provide some kind of interface for working securely with shell commands? Otherwise
you are stuck with having to weaken security to enhance password security. Catch 22.

This is one of those no win situations. Almost all workarounds will have possible security issues. Unless ERP thought out of the box.