On Mon, May 2, 2011 at 08:17, Jim Gibson <jimsgib...@gmail.com> wrote:
>
> At 10:46 PM -0400 5/1/11, shawn wilson wrote:
>>
>> jim, you setup your boxes a certain way to make sure this doesn't fail?
>
>
> No. The systems are plain vanilla Red Hat Linux (old versions because they 
> run proprietary software).
>
>>
>> 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.
>
>
> It doesn't matter what encryption scheme the systems are using, as long as 
> they all use the same one. I am distributing the encrypted versions of the 
> passwords from one machine (the master) to the rest. I am not generating the 
> encrypted passwords myself.
>
>>
>> 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.
>
>
> These systems are not on the internet. When I am changing the password files, 
> I am the only user on the system. My program is not making any system calls. 
> It is modifying the password file directly with simple string replacement.

Jim;

  It looks like you have a great working system for annually forcing
the change of UNIX passwords in a systematic manner, but it would
definitely not be good to emulate your system in the general case
because very few people on this list (I'm betting here) are in such a
situation, as you have described in your answer to Shawn.  Your
script(s) work almost flawlessly without the controls normally very
necessary because you have externally controlled the conditions so
thoroughly.  Therefore your solution is definitely not one that can be
emulated generally.

IMNSHO,
Ken Wolcott

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to