Thanks to
Mark Ray
Shawn Leard
John Ferlan
John mentioned that I could use "/tcb/bin/edauth -g <username>" to verify
if my new user was in the enhanced security database or not. I was having
trouble with passwd not recognizing a new user.
As it turns out many of my troubles were due to a lack of understanding
about how the enhanced security default template works. I had assumed that
the attributes set in the template would only apply to newly created
users. In fact, they apply at once to existing users (who have that
template selected as part of their account attributes). I had modified the
login resources options of the default template to reduce the virtual
memory users would have available. Most of my users are programming
students and I didn't want an incorrect program to eat all of memory
accidently. As it turned out, this action left root with too little memory
to run CDE.
When I realized that this was probably what was happening, I manually
edited /etc/auth/system/default to remove the restrictions. Root was then
once again able to log in at the console using dtlogin. Strangely this
also appeared to fix my issue with passwd not recognizing my new user.
However, it may be that I did something else that fixed that. I'm not
convinced that it was directly related to my virtual memory issues.
So all is well except for one minor thing: It is still true that a
non-root user can't log in at the console in command line mode. The
dtlogin program keeps interrupting such a session. Root can log in at the
console fine either graphically or via the command line session. A non
root user can log in at the console fine via dtlogin and can telnet into
the machine fine. Mark suggested that perhaps the permissions on
/dev/console might be wrong. He said that they should be root:daemon. In
fact, my /dev/console has permissions of root:terminal. I tried changing
them to root:daemon, but they just got changed back again shortly
afterwards. I'm still interested if anyone has any ideas about this one,
but it's not a high priority for me right now.
Quick question: do the locking criteria in the default template apply to
root or is root handled as a special case? I'd hate to think that someone
could lock root's account by just trying to log in as root a certain
(fairly small) number of times. Perhaps root is always allowed to log in
at the console? Or should I create a special set of security attributes
for root?
My original message is show below:
-----> cut here <-----
Date: Wed, 20 Jan 1999 08:15:13 -0500 (EST)
From: Peter Chapin <pchapin_at_solstice.vtc.vsc.edu>
To: OSF Managers <alpha-osf-managers_at_ornl.gov>
Subject: Strange problems logging into the console.
Followup-To: poster
Greetings!
I just did a fresh install of DU 4.0D. I activated enhanced security and
applied jumbo patch #3. Next I configured the default user template for
the password controls, login restrictions, etc that I want. I then created
a user. Everything seemed normal enough. However, I then encountered the
following problems:
1. I attempted to log in as my new user in a command line session on the
console. This acted oddly because the dtlogin screen kept coming back
every few seconds. Note: My new user's password expired at once so I was
trying to set a new password at the time. Yet even after I managed (with
difficulty -- I had to constantly go back to the "command line session")
to get my new user logged in, the dtlogin screen continued to interrupt my
session.
2. I managed to log my new user out. I then tried to log in as root using
dtlogin. When I do this the screen clears and I see "Starting CDE
Environment" and then the screen immediately returns to the dtlogin
screen. Just before the screen clears I can see some messages being
written into the console log window. However I can't read them. They say
something like "fatal error... can't load {somesuch}." I *can* log in as
root in a command line session and that seems to be well behaved.
3. When I try to modify my new user's password with passwd, I'm told the
user does not exist. However, the user does exist (I can see the entry in
/etc/passwd!). For fun I ran mkpasswd on the password file, but that did
not fix this issue.
My questions:
a) Is the console log written to a file some place? I'd love to read those
messages once I get logged in using the command line.
b) Why does my root graphical login no longer work?
c) Why did dtlogin keep interfering with the command line login of my new
user?
d) Why does passwd believe my new user does not exist?
-----> cut here <-----
*****************************************************************************
Peter
pchapin_at_solstice.vtc.vsc.edu
http://solstice.vtc.vsc.edu/~pchapin/
Received on Thu Jan 21 1999 - 18:25:34 NZDT