From: Paul L. <pa...@sq...> - 2008-01-28 04:07:07
|
On Jan 25, 2008 12:35 PM, Kaplan, Andrew H. <AHK...@pa...> wrote: > Hi there -- > > NOTE: If you want me to reply without the history, let me know, and I will do so > from here on. Replying with context preserved is essential, but I am not clear what you did - you seem to have replied in-line, which is perfect, yet there is also a copy of my original message below? That should not be necessary. > > *10*4750? Strange. Show a directory listing of the directory where > > this file resides. > > Per your request, the directory listing for chpasswd is shown below: > > /usr/share/squirrelmail/plugins/change_passwd > -rw-r--r-- 1 root root 39 2008-01-25 13:10 1 > -rw-r--r-- 1 root root 2481 2006-09-08 14:45 change_passwd.pot > -rwsr-x--- 1 root apache 10868 2006-09-12 06:45 chpasswd > -rw-rw-r-- 1 root root 7360 2006-09-12 06:45 chpasswd.c > -rw-rw-r-- 1 root root 2906 2008-01-25 13:48 config.php > -rw-rw-r-- 1 root root 2906 2006-09-10 04:26 config.sample.php > -rw-rw-r-- 1 root root 15802 2004-11-28 03:30 COPYING > -rw-rw-r-- 1 root root 610 2004-11-28 03:30 exec_test.php > -rw-rw-r-- 1 root root 881 2006-09-08 13:30 functions.php > -rwxrw-r-- 1 root root 388 2005-11-22 03:56 getpot > -rw-rw-r-- 1 root root 486 2004-11-28 03:30 index.php > -rw-rw-r-- 1 root root 2343 2006-09-12 06:40 INSTALL > -rwx------ 1 root root 5793 2006-09-12 06:53 make_release.sh > -rw-rw-r-- 1 root root 17787 2006-09-08 14:44 options.php > -rw-rw-r-- 1 root root 11232 2006-09-12 17:54 README > -rw-r--r-- 1 root root 1221 2006-09-12 18:02 setup.php > -rw-rw-r-- 1 root root 24 2006-09-12 18:02 version > > One thought came to mind...while the chpasswd user and group ownership is set to > root:apache, should the remaining files in the directory also have a similar set > of ownership? Absolutely not. > The chpasswd shown below is that which is in the /usr/sbin directory: > > /usr/sbin > -rwsr-x--- 1 root apache 31292 2007-04-10 06:18 chpasswd Which one did you configure the plugin to use? For kicks, configure it to try the other one, whichever that might be. Once you have one working BE SURE to remove suid privilege on the one you are not using and REMOVE apache access to it completely. > > I don't quite understand. Are you saying that when you execute the > > command (given above) on the CLI, it changes the password > > successfully, but when done in SM it does not? If so, this indicates > > that there is a problem getting PHP to run the command correctly. > > Please inspect your PHP error reporting settings (turn them all the > > way up) and see if you are using safe_mode or any similar security > > settings. > > Sorry about that, when the command is executed at the CLI, the password changes > without a problem. The disparity occurs when it is done through the web > interface. I verified that safe_mode for php is not turned on. Also, I > configured php to report all errors. Once that was done, I went through the > process of changing a user's password. There were no errors that appeared > on-screen. Nor in the web server error log? If the plugin appears to think the password was changed correctly, you can try to turn on debug mode and change it. Or try to sniff the connection yourself. > There was one difference this time. After the change was made on the web > interface, the user was able to connect via ssh to the server using the new > password. Oh, so it did work. > However, the warning that the password in question would expire > in several days still appeared on-screen. The chage -l command confirmed the > password had not been changed today. That makes a little more sense. The plugin probably is not resetting that field in the password file. I don't recall if it even tries to do so, but you should look at the C source and see - I don't remember if you can configure it to do so or not. > > If the utility does not work on the CLI either, it's either not > > compiled correctly, or some other issue - perhaps your passwords are > > not stored in the typical location. You might need to sniff the > > actual connection being made when the change occurs. > > The location of the passwd and shadow files is in the /etc directory. They > are shown below: > > -rw-r--r-- 1 root root 3531 2008-01-25 01:00 passwd > -r-------- 1 root root 3069 2008-01-25 14:51 shadow > > > > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf Of Paul > Lesniewski > Sent: Friday, January 25, 2008 2:51 PM > To: Squirrelmail Plugins Mailing List > Subject: Re: [SM-PLUGINS] Change_passwd plugin does not change user > accountpassword > > > I have a system running Fedora Core 7 with SELinux set to permissive mode. > > The version of SquirrelMail is 1.4.10a-1.fc7, while > > > > the compatibility plugin version is 2.0.9-1.0, and that of the change_passwd > > plugin is 4.2-1.2.8. > > > > The user interface to change the password does appear to be working properly > > in that there are no apparent errors appearing > > > > even when the seeoutput and debug options are activated. The output from the > > debug flag being activated is shown below: > > > > Permissions of chpasswd executable are: 104750 > > *10*4750? Strange. Show a directory listing of the directory where > this file resides. > > > chpasswd has group ownership: apache > > Your web server is running under group: apache > > > > chpasswd is owned by: root > > > > To test the chpasswd utility from the command line, do this: cd > > /usr/share/squirrelmail/plugins/change_passwd > > ../../plugins/change_passwd/chpasswd 'username' 'old password' 'new > > password' 2>&1 > > > > The chpasswd binaries in the plugin as well as the /usr/sbin directories > > both have the 4750 permissions as well as the root:apache > > > > ownership. The Apache server on the system is owned by the user and group > > apache. > > > > The problem that I am seeing is that even though the plugin says a user > > password was changed successfully, when I run the chage > > > > utility on the server, the output it produces does not reflect the change > > being made through Squirrelmail. Furthermore, if the user logs > > I don't quite understand. Are you saying that when you execute the > command (given above) on the CLI, it changes the password > successfully, but when done in SM it does not? If so, this indicates > that there is a problem getting PHP to run the command correctly. > Please inspect your PHP error reporting settings (turn them all the > way up) and see if you are using safe_mode or any similar security > settings. > > If the utility does not work on the CLI either, it's either not > compiled correctly, or some other issue - perhaps your passwords are > not stored in the typical location. You might need to sniff the > actual connection being made when the change occurs. > > > into the server via an ssh connection, the password that was supposedly > > changed through SquirrelMail is not reflected there. > > > > What other setting(s) do I need to adjust in order to correct this? Thanks. > > The information transmitted in this electronic communication is intended > > only > > for the person or entity to whom it is addressed and may contain > > confidential > > and/or privileged material. Any review, retransmission, dissemination or > > other > > use of or taking of any action in reliance upon this information by persons > > or > > entities other than the intended recipient is prohibited. If you received > > this > > information in error, please contact the Compliance HelpLine at 800-856-1983 > > and > > properly dispose of this information. |