pw_id_map treatments and patchkit questions

From: Martin Mokrejs <mmokrejs_at_natur.cuni.cz>
Date: Thu, 26 Nov 1998 19:18:26 +0100 (MET)

Hello,
 looking forward to the jumbo#3 for 4.0D which is said to be released on
27/11/98 I came through all bug I've ever met on 4.0D (just so summarize
myself, what fixes to look for). The README-3-19981120.txt distributed
with the jumbo does not mention pw_id_map file, so I don't know if there's
still problem described below. Can someone from Compaq people dig out some
more info? ;-))

BTW.: No, I don't have the patch yet, I just got the README. :(
Is possible to legally create a mirror of Digital's patch directory
somewhere outside, or do we all need to download it directly from US?
Can I make the patch available (legally) to others to save bandwidth?

--
Martin Mokrejs - PGP 5.0i key at: finger://mail.natur.cuni.cz/mmokrejs
<mmokrejs_at_natur.cuni.cz> Faculty of Science, The Charles University
---------- Forwarded message ----------
Date: Tue, 17 Mar 1998 14:43:31 -0600 (CST)
From: Kevin Houle <kevin_at_netins.net>
To: alpha-osf-managers_at_ornl.gov
Followup-To: poster
Subject: SUMMARY: /etc/auth/system/pw_id_map
The /etc/sia/matrix.conf (in the case of C2, /etc/sia/OSFC2_matrix.conf)
provides the matrix that selects the appropriate installed security
mechanism when a security-sensitive command is executed. I'm figuring
calls to the SIA subsystem cause "the system" to check consistancy of
the /etc/auth/system/pw_id_map file. I presume "the system" to be 
libsecurity.
Well, in our case, SIA calls are being made faster than the pw_id_map
file can be rebuilt by "the system". A normal event, like a password
change, causes pw_id_map to rebuild. While pw_id_map is being built,
an SIA call comes in, the system checks pw_id_map and finds it isn't
consistant, wipes it and starts a rebuild. Another SIA call comes in
before the file is built, the system wipes the file and starts over.
The result is a pw_id_map that churns, a system which drowns in
backlogged SIA calls, and users who call wondering why POP3 e-mail
is timing out.
In my opinion, this is a denial of service issue with DEC's C2 
subsystem. The rebuilding of pw_id_map (and perhaps gr_id_map)
should lock so as to avoid another evaluation/rebuild to stomp 
the process and cycle the machine to death.
FYI- This problem is happening on a machine that does 140,000
qpopper2.4 calls to getespwnam() per day.
--
Kevin Houle
netINS, Inc.
---------------- Original message follows ----------------
 From: Kevin Houle <kevin_at_netins.net>
 To: alpha-osf-managers_at_ornl.gov
 Date: Tue, 17 Mar 1998 10:04:28 -0600
 Subject: /etc/auth/system/pw_id_map 
--
Under DU 4.0B and C2 security, we're seeing /etc/auth/system/pw_id_map 
go into loops of rebuilding itself over and over and over again. This
is causing I/O churn on the system disk, blocking of authentication
requests, and high system loads.
According to DEC documentation :
The /etc/auth/system/pw_id_map file is the user name to ID mapping 
database. This file must be consistent. The system rebuilds this file 
if it is not present. 
Does anyone have anything more specific than "The system rebuilds
this file if it is not present"? Why would it rebuild over and over
again? It does this without passwd being in use, or any account
creation activity or changes to /etc/passwd happening at all. The
main user of authentication is qpopper2.4, which is using the
getespwnam() and getpwnam() calls.
Is there a kernel parameter which controls the rebuild of this
map file? Something else?
Thanks,
--
Kevin Houle
netINS, Inc.

Received on Thu Nov 26 1998 - 18:19:43 NZDT