crawford@ENUXHA.EAS.ASU.EDU (Brian Crawford) (05/11/91)
Since my original post of a problem, several people have been most helpful
both on the here and by direct email and is _most_ appreciated. However,
there were a few details painfully missing from my first posting and would
like to again post the problem with more complete details.
Operating system: SCO XENIX SysVr2.3.2
Hardware: 80386 clone, 33 MHz
4 MBytes RAM
PC VGA Monitor/101-key keyboard as system console
1 Serial terminal, using Odd Parity.
1 Digi/Board 8 port card. Serial card is connected
to this.
Symptom of problem: The first 'login:' prompt looks like:
XENIX!386
login:
1. If the 'root' user logs in, it prompts for the password
just fine, and am place at the normal shell prompt.
2. But, if I login in as any other non-superuser, it will
also logon PROVIDED THAT THERE IS NO PASSWORD SET FOR
THE ACCOUNT.
3. If I login as any non-superuser which requires a
password to complete the login procedure, the
terminal appears to 'freeze' after the non-echoed
password is entered- that is to say that no NL is
echoed to the screen.
Further, nothing happens at this point at all unless
two more carriage returns are entered. If this is
done, at that point another login prompt appears
(without the XENIX!386 part).
These subsequent 'login:' prompts will echo nothing to
the screen when a userid is typed in.
If any typo error is produced at the keyboard while
trying to login as 'root', the same symptoms listed
under "3." here are encountered.
4. If, after the first failed attempt, one waits 1-2 mins,
the session seems to reset back to the first login
prompt and seems to execute a login just fine for the
'root' or any non-superuser who's password is not
set.
Something different about this installation, the serial terminals are
constrained to Odd Parity, which has been set in the gettydefs both in the
second and third fields of the 'm' line.
Perhaps this is a serial port problem here, but since this problem only
happens with login's other than the root it is not obviously aparent that
it is a communication problem. Further, these symptoms occur on both the
serial terminal AND the main PC console. It doesn't matter where the login
session occurs. This would seem to indicate a file protection problem.
But, all protections have not been changed.
Unfortunately, the 30-day SCO warranty of support is expired and the software
to be used on the system by the users has only recently arrived and the need
to use the non-superuser id's enough to discover the problem occured only at
this time.
How strict is SCO in a situation like this? I called and explicitly asked them
about help with the expired warranty- w/o mentioning the problem- and they
told me the purchase of an additional support contract would be necessary.
This is not possible.
Comments appreciated.
-------------------------------------------------------------------------------
Brian Crawford INTERNET (current): crawford@enuxha.eas.asu.edu
PO Box 804 (permanent): crawford@stjhmc.fidonet.org
Tempe, Arizona 85280 FidoNet: 1:114/15.12
USA Amateur: KL7JDQ
-------------------------------------------------------------------------------rwhite@jagat.uucp (Robert White) (05/13/91)
Ok, little things first: The XINX banner before login: is provided by gettys. After you type a string to gettys it execs login(1) with that information so it is normal to loose the header info on unsuccessful attempts to log in. Second and subsequent "login:" messages come from the login program directly. Login does not possess builtin banners as some versions of gettys do, nor does it read /etc/gettydefs for the login prompt information. You get the password wrong and login just spews out "login:" in an attemtp to give you a second chance without hanging up the phone. Similarly, login will kill itself and init will respawn gettys if either too much times passes or to many unsuccessful login attempts are gone through. Typical stats are 2 min or 5 tries. gettys and login are run with root permissions. When the identity of the user has been established login looks up the starting shell in the password file and writes that information into the utmp file, changes it's real and effective user and group ids as approprate and then execs the indicated program. Normally something like /bin/sh. The shell runs /etc/profile and then the users .profile and then provides the normal prompt. /etc/profile is not optional but .profile is. Taking everything you say into account, the fact that the symptoms are the same for the console and the terminals and that you can log in a root, but nobody else says that whatever is going wrong happens after the set-user-id phase of login. Something that needs *must* be accessable by the user is not. My best guess would be that you have replaced and/or copied over /etc/profile and that it is no longer readable by others. Or the shell itself is not readable and executable by others, but that is a much less likely possibility. Since root can read everything the /etc/profile and /bin/sh permissions problems are most likely, the obscurity of the /etc/profile makes it a better canidate for overlooking. Chances are the login mechanisim is still in perfect working order. To check it, replace/fill-in the last entry of the password file for a "normal user" with a command that is harmless and produces definite input. /bin/who should do nicely. If the command runs when you attempt to login then the problem has to do with the shell. If the command does not you should check /etc/passwd or /etc/shadow (if your system supports it maybe even pwunconv and pwconv the file to recreate it) and whatever else is used durring login. Make shure you have room on you root file system for the utmp and wtmp entries and check all the log files under the login manual page to make shure they have been cleaned out lately. Running out of disk space, or even getting close can mess up mundane things like shell pipelines and such, if any of your filesystems (esp the root and pipe file system which are usually the same thing) are nearly full you can get strange behavior. Well, I am sick and I have free-associated long enough. Hope my rambling helped. -- Robert C. White Jr. | I have moved my news reading activities rwhite@jagat <Home | not directly related to my job off of my rwhite@nusdecs <Work | employers machine. Please use "jagat" "Like most endevors, life is seriously over-advertised and under-funded"