SUMMARY: [Help! All users' passwd lost]

Date: Sun Mar 29 1998 - 06:40:53 CST

Hi All,

Here is the summary.The following deserve thanks for thair responses:

 Brion Leary <>
 Matthew Stier <>
 David Thorburn-Gundlach <>
 Alessandro Forghieri" <>
 Ozgur Erk <>
 Amjad Zamel <>
 Flavio Elizalde <>
 Ulan Mamytov <>
 Coffindaffer, Virginia <>
 Karl Vogel <>
 Jim Robertori <>
 Aaron Lineberger <>
 Rich Snyder <>
 Joel Turoff <>

My Question is:
> Dear Sun Managers,
> I'm working for an ISP. Our mail server and users accounts are
> on a Sun Ultra-2 runing Solaris 2.51.
> To prevent users from telnetting to the server(for security),
> I disabled the telnetd. But after that our users can't run passwd
> to change their passwords. I wrote a CGI program to let our users
> change their passwds on web. In the first week,it works well.But this
> afternoon,it's a nightmare to me. When I added a new user,I found my shadow
> file are erased!:-( I lookup my log of that CGI.There is a request at
> the same time. I think it must has conflict between CGI and the passwd
> command. But I don't know how to correct it.
> I can't find the source code of passwd. I don't know how it works.
> But in an old sun document,I find a introduction of how to change
> passwd. I write a similar program like this:
> 1.Create a unique temporay file such as /etc/spw$$.
> 2.Link the temp file to /etc/stmp. If the link fails,remove the temp
> file and exist;somebody else is modifying the shadow file.
> 3.Read from /etc/shadow with successive calls to getspent(),and
> write to /etc/stmp with successive calls to putspent(),making changes
> as necessary.
> 4.Move /etc/stmp to a backup file /etc/oshadow
> /etc/stmp to /etc/shadow.
> 6.Unlink temp files,/etc/stmp and /etc/spw$$
> I have read the source code of Linux passwd.But it is much different
> from Sun. To cooperate with the passwd command,I have to know how sun
> change password.I know it is dangerous to change shadow directly,but I
> have to do it:-(
> Can anyone help me?
> Thanks in advance.

I got many responses that suggested me to enable telnetd and change
the shell to "/bin/passwd" instead. The another solution is expect,which is a
tool for automating interactive applications such as telnet, ftp, passwd, fsck,
rlogin, tip, etc. The homepage of Expect is
I used both solutions. First changing user's shell. And for those don't know
how to telnet and passwd command, I write a expect CGI to change passwd
on web.
It works well till now. Because I use passwd command to change password,
it's no need to worry about the cooperation between my cgi and the
passwd command.

The following is the detail response:

Re-think the problem. You should not modify /etc/shadow -
Sun doesn't support it. You should not run a suid change password
program via CGI - bad security risk.

The following works on Sun OS 4.1.3 -
(1) ENABLE telnetd
(2) change users' login shell to /usr/local/bin/chp
(3) compile this program and put it in /usr/local/bin
main() { (void)execl("/bin/passwd", "/bin/passwd", (char*)0) ; }
(4) IF ftp access is needed for these users, add /usr/local/bin/chp
to /etc/shells ; if /etc/shells doesn't exist see ftpd man page.

Brion Leary <>

Why not, instead, have a CGI script that takes the old and new
passwords and then feed those to expect and just use Sun's passwd
program to change the passwd as a normal user would? You can find
expect in a number of places, and it's perfect for this sort of


David Thorburn-Gundlach         * It's easier to fight for one's principles
(play)        * than to live up to them. -- fortune cookie
(work)   Helping out at Pfizer

======================================================== i) I do not think that you ran into a passwd bug - rather some file locking misstep. If passwd is buggy that way, then the situation is hopeless. Getting file locking right is rather tricky, so much so that - even though I have been mucking around this job long enough to know some things on this sort of stuff - would not attempt to do it at a home-grown script level on something as critical as the password file. Surely not at a shell script level, where features like flock(2) are not present.

ii) If you must use the web, I would look at running passwd through expect (look for it on many Tcl sites). That should give you most of the funcionality you are looking for and it comes with examples. Also the Camel book has a sample script for changing passwords (shadow support included). This script also has a bug in how the 'salt' is computed, so you should actually look for the updated version.

iii) If you run telnetd under the TcpWrappers, you could consider restricting access to the proper IP and replace the user shells with the passwd command (yes, that works, I tried it): as a bonus, they will not be able to ftp as themselves (unless you stick passwd in /etc/shells).

iv) Me, I do not let the user change their passwords. We do it, & we make sure it is a process incovenient enough - for the users - that we do not have to do it often. The rationale for this is:

o) We let the users change their passwords, they will make mistakes, forget them, then we'll have to reset them anyways.

o) They always end up choosing something like 'Maria' as their password.

o) Even as things are, after we change a password, they fail to tell all the people that use the account, who then call us to ask the new password. Then, they forget about the change, and call to ask why they cannot read their mail anymore.

o) We set their shell at /bin/false,use /bin/true for those that need ftp, and keep using telnetd.

I am not saying this is the cure. It is just what I do.

HTH & cheers, Alessandro Forghieri ---- Alessandro Forghieri Sitemaster-Nouvelle srl voice: +39-59-345767 Via Giardini 460 41100 Modena ITALY ========================================================= I run a ISP too. We have adopted the following solution: in order to avoid giving a full shell to users acessing via telnet I created a restricted shell: ish

I put it on /bin and all user account have /bin/ish as their shells. So we didn't blocked the telnet access, but the only thing users can do is to change the password. This system has worked for the last 2 years with no erro, no passwd losses and no hackin problems.

This is ish shell, you can use if it helps. The comments are in portuguese, but the command are straight forward...


# # Define variaveis # USER=`/usr/ucb/whoami` LOG="/var/adm/ishlog" WHO=`/bin/who | /bin/grep $USER `

# # Apresenta o menu de comandos #

# This is the choice menu 1 is change passwaord 2 is exit

echo " " echo "Escolha um dos servicos:" echo " " echo "1) trocar senha de acesso;" echo "2) saida" echo " " echo " "

# # Espera resposta do usuario # echo "Entre com o numero do servico desejado:" read COM echo " " case $COM in 1) # Troca de Senha echo $USER":troca de senha \\c" >> $LOG /bin/date '+em %d/%m/%y (%a) %H:%M:%S'>> $LOG /bin/passwd echo $USER":troca bem sucedida!" >> $LOG echo $WHO >> $LOG ;; 2) # Saida echo $USER":saiu do ish \\c" >> $LOG /bin/date '+em %d/%m/%y (%a) %H:%M:%S'>> $LOG echo $WHO >> $LOG exit ;; esac /bin/ish exit


Flavio Elizalde - Webmaster | e-mail: ICONet - Provedor de Acesso a Internet | Tel./Fax: (012) 341-1256 Vale do Paraiba - SP - Brasil | WWW : ===================================================== Instead of disableing telnetd why don't you do something like the following, it works perfect for us running 2.5.1 and NIS:

Add the following to your /etc/passwd file on each server:

+@servers::0:0::: +::0:0:::/opt/local/bin/message

Add the following to /etc/shadow file on each server:

+@servers::6445:::::: +::6445::::::

In nsswitch.conf file change the passwd entry to:

passwd compat

In essence what this does is gives access to only the people in the servers group of the NIS netgroup file, and if anyone else logs in they get the message:


Sorry, you are not allowed to log into this host.


I'm sure there are other ways to set this up to configure it to your system, but this seems like a more viable solution since you don't have to disable telnetd, which could as you have found cause problems.

----------------------------------------------------------------------------- Aaron Lineberger ODUCS Systems Group Asst. Systems Engineer ----------------------------------------------------------------------------- ============================================================

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:34 CDT