Re: [SM-PLUGINS] Research -- change_passwd-4.3beta7-1.2.8.tar.gz -- FreeBSD-7.1-RELEASE

[Paul L. <pa...@sq...>]

On Thu, Sep 9, 2010 at 5:07 PM,  <sm...@gu...> wrote:
> I hope this is not a really silly mistake on our end.
>
>>> $pathToPw = '/usr/sbin/pw';  &#61663; this is where ‘pw’ is on
>> If you are using this, then you DO NOT need to compile the program that
> comes with the plugin, as it is not used.  However, please READ the
> security warnings about using "pw", though, and show its
>> permissions so we can validate that it is executable by the web
>> server.  Also, try executing it yourself as the web server.  Maybe,
> starting as root, something like (change "apache" to the right
>> username):
>
> Only chose this (above) because chpasswd didn't respond well
>
>>> # Oh well, one (1) out of two (2) ins’t that bad.
>> You mistake warnings for errors.
>
> Understood.  Are you saying that in this instance it successfully compiled
> --with 'warnings?

Seems like it

>>> <prompt># chpasswd 245 <correct.current.passwd> <new.passwd> from the old
>>> and now deleted installation.  This says to me; the original chpasswd
> supplied from the tarball is no different than the one (1) that was
> currently compiled with ‘gcc –isystem’  yes/no?  --i.e. with regards to
> the results.
>> No, if the crypt.h error is not showing up, presumably the code
>> compiled closer to correct.  I don't remember how the code pulls the
> current password, but it is entirely possible that it is looking for it
> in a place that BSD does not keep it, or the crypt() code isn't working
> in a way that complies with BSD-generated passwords.
>> Where are your encrypted passwords?  /etc/passwd?  /etc/shadow?
>
> They are in /etc/passwd
>
>> There is a debug "printf" statement in the source code on line 166 (or
> just search for "Current password is incorrect").  You might uncomment
> that line (by removing the first to forward slashes) and re-compile and
> report the results.
>
> I'll look into that now.
>
>>> Waiting for the ‘SM Dev Team’ to provide more enlightenment.
>> This is a third party plugin for which the SquirrelMail Project Team is
> not responsible.
>
> Oh yeah, oops (above)
> --------------
>
> In the mean time I put the config.php back in its native form; the results
> are shown below; continues to not change any passwords.
>
> SM-1.4.21 > options > change password
> Old.pass
> new.pass
> confirm.new.pass
> RESULTS: An error has occurred while attempting to change your password.
> Please contact your system administrator. At the top of the change
> password option page.
>
> Remember you asked where I got that error from and I couldn’t remember,
> there it is.  In an attempt to fix the above, we now use: chown root:www
> chpasswd ; chmod 4750 chpasswd; I forgot we just did a compile of
> chpasswd.c.  Now let’s try again and change the password from within--
> SM-1.4.21 > options > change password.
>
> The entire right-frame changes to a gray-bkgrd with the following:
>
> Permissions of chpasswd executable are: 104750
>
> To test the chpasswd utility from the command line, do this:
> cd /usr/local/www/squirrelmail/plugins/change_passwd
> ../../plugins/change_passwd/chpasswd '245' 'current.correct.passwd'
> 'new.passwd' 2>&1
>
> Ok. Lets go to the cli ….
> <prompt># pwd
> /usr/local/www/squirrelmail/plugins/change_passwd
> <prompt># ./chpasswd 245 'correct.current.passwd' 'new.passwd'
> Current password is incorrect
> <prompt># ./chpasswd 245 'correct.current.passwd' 'new.passwd' 2>&1
> <prompt># ./chpasswd 245 correct.current.passwd new.passwd
> Current password is incorrect
> <prompt># ./chpasswd 245 correct.current.passwd new.passwd 2>&1
>
> What could I have possibly done incorrectly this time around?  This is
> what prompted us to re_read the INSTALL and decide to use the ‘pw’.  In
> doing so I got confused while bouncing back and forth from page to page,
> window to window and staying focused.
>
> So, to borrow your word ‘consistent’, chpasswd is consistently giving us
> grief and is not yet happening on this FreeBSD-7.1_RELEASE machine.
> Please correct me/us-- what was just demonstrated above is the ‘chpasswd’
> binary not properly functioning both from within SM and on the cli; if
> there is a setting I missed please point it out.
>
> Prior to this point in time, was nothing short of lack of knowledge
> coupled with confusion by setting the ‘$pathToPw = ''; directive. Which
> I’m quite sure I still don’t understand its usage via the plugin.  I
> thought the plugins’ ‘change password’ page would use the systems ‘pw’; am
> I wrong (again)?  If it’s not using the systems ‘pw’ how to troubleshoot
> this.

The plugin either uses its own chpasswd binary to edit the password
file, or on BSD systems, you can choose to use the built-in "pw"
binary.  As I mentioned several times, there are some security risks
with the latter, so you should read about them in the README file for
the plugin.

> Two (2) outstanding issues: the plugins chpasswd and the plugins use of
> the systems ‘pw’ is not functioning.

I asked you to run some tests for "pw" in my previous email as well as
asked for some debugging output from chpasswd.

> FOR COMPLETENESS:
>
> Testing exec()...
> safe_mode =
> safe_mode_exec_dir =
> ________________________________________
> return value = 0
>
> output:
> Array
> (
>    [0] => 1
>    [1] => README
>    [2] => chpasswd
>    [3] => chpasswd.c
>    [4] => config.php
>    [5] => config_default.php
>    [6] => config_example.php
>    [7] => docs
>    [8] => exec_test.php
>    [9] => functions.php
>    [10] => index.php
>    [11] => locale
>    [12] => make_release.sh
>    [13] => options.php
>    [14] => setup.php
>    [15] => version
> )
>
>
> This is what prompted us to set the directive and employ the systems ‘pw’.

-- 
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donate_paul_lesniewski.php