Consultor Eletrônico

Status: Verified

SYMPTOM(s):

Logouts show as blank users in the database log file

The user logins do show in the database log

Login by <user> on <ttyxxx>. (452)

Logout by <user> on <ttyxxx>. (453)

11:34:13 Usr 18: Login by bshanie on /dev/pts008. (452)

11:34:20 Usr 18: Logout by on /dev/pts008. (453)

Users are not logging in as blank users

FACT(s) (Environment):

Progress 9.x
All Supported Operating Systems

CAUSE:

Users have not been added to the _user table

When we say that a blank userid has been denied access to
the database, we do not mean that a blank userid cannot connect to the
database. In the 4gl scheme of security, there is AUTHENTICATION, and AUTHORIZATION.
The authentication part consists of getting the system to accept a user with a
certain userid (who am I). The authorization part consists of granting
access to data for a certain userid (what can I see). If you have no _user
records, authentication is done by the operating system and we use the logon
id to decide who you are. The -P and -U parms are invalid for this case.
If there are _user records, we pay no attention to your logonid, and we log
you into the database as the blank userid, in order to read the _user table.
If you have given -P and -U, we will allow you to become the user from -U
if the -P password check succeeds. In all other cases, you become the BLANK
user. ANYBODY can log into a 4gl controlled database as the blank user.
Denying the blank user rights thru our dictionary does not pretend to stop
this. Instead, we then depend on the second part of our security, which
is authorization, which compares the userid you have with the CAN-* fields
in each schema record. When you disallow the blank user in the dictionary,
we just make !BLANK occur in all your CAN* fields, so the blank user cannot
access anything.

FIX:

Add the users in the Progress Security (Admin>>Security) so that they will then be added to the _user table.