jim, you setup your boxes a certain way to make sure this doesn't fail? On Sun, May 1, 2011 at 10:17 PM, Jim Gibson <jimsgib...@gmail.com> wrote: > At 5:22 PM -0700 4/30/11, dolphin wrote: >> >> Hi, >> >> To reset password in unix, the system will prompt 2 times for entering >> the new password. The first time is to enter the new password and the >> second time is to confirm the new password of the account. It is >> tedious to perform this when there is a huge volume (>100) of user >> accounts. Is it possible to write a perl script that read from a file >> that contain the password of the user and automate this? > > I do this once a year to update a set of passwords on a set of hosts using a > Perl script I wrote. > > The procedure: > > Manually change the password for all relevant accounts on one system. > Copy the password file (/etc/shadow on my Red Hat Linux systems) to a file > server accessible to all systems. > Place a copy of the script on the same server. > Log into to each system as root and run the script, which parses the new > password file and replaces the old encrypted passwords on the target system > with the new, encrypted passwords from the server copy file. > Clean up by erasing the new password file and script from the server. > Done! >
so, the problems i see with this: 1. password schema - newer systems use sha whereas older systems use md5. 2. seed - i 'think' pam with sha allows seeds - if the seeds aren't the same, you break stuff this way. 3. don't put a password file on another machine unencrypted. that has all sorts of 'not good' written all over it. > Password files are easy to parse, so I have never felt the need to use a > module. > yeah, he could look at what pam is using (or maybe something else) and use one of the crypt:: modules to write the hash, but... > You have to be very careful since you are running a script as root. My > program reads the local password file, reads the common password file, > writes a new local password file, runs the diff utility on the old and new > local files, and displays the result to the user, prompts the user to > proceed (or abort), then renames the old local file as a backup, and renames > the new local file as /etc/shadow. > hummm, i'm sure there's a way for a user to poison a password file so that when you parse it, some evil happens. maybe make the full name field 'rm -rf /' or maybe unlink something... just saying system calls like that need to be thought out pretty carefully. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
