From: Jay R. Wren (jrwren@oakland.edu)
Date: Thu Jun 20 2002 - 09:14:53 EDT
Hello Managers,
We have a handful of Digital Unix 4.0d and Tru64 Unix 4.0f systems
running in Enhanced Security Mode. Recently some folks (fellow admins)
have thrown out the manual and decided to try deleting user accounts
anyway. The entry is removed from the password file (/etc/passwd) and
the tcb record removed. This is not a problem. The problem comes when
the same username, call him bob, is added again. bob had a uid of 1234
but was deleted. Now someone has added him again with the uid of 5678.
The password file and tcb file show bob with a uid of 5678. I am using
edauth -g to look at the tcb entry. The problem is that 'id' and any
other program resolves the name bob to uid 1234. Indeed the getpwnam()
function call returns as passwd structure with a uid of 1234.
Interestingly, getpwuid when called with uid 5432 returns the bob
passwd structure that is in the password file with a uid of 5432. Most
interesting is that when I run authck I do not get the username bob
listed as having any issues or duplicates.
The big question: Where is this entry coming from?
In an effort to answer this question myself I decided to take the
command '/usr/bin/id' and run it through the debugger. I set
breakpoints at each open and close system call using the debugger
command 'stop at open' and 'stop at close'. I then ran the command and
would look at the output of lsof at each step along the way. I did not
notice any files of interest at these open and close calls. It seemed
to be openning the pty for STDIO. I would have guessed that the id
command would call getpwnam or getpwuid, and that these calls would have
openned some files. The manpage for getpwnam and getpwuid are not
system call pages and are part of libc, I would think they would execute
in user space and not be kernel type system calls. So any files opened
by these functions would be part of the called executable and not
handled by a different process.
After writing the above I revisited the tcb files again. On system4 I
noticed bob 1234 in a file /var/tcb/files/file. I tried renaming this
file, modifying it, no results. On system3 I do 'strings
/var/tcb/files/auth.db' and get two longan entries:
bob
bob:u_name=bob:u_id#1234:u_pwd=2Nb.aOc7TbwHUvrZUrrzWHls:u_oldcrypt#1:u_suc
log#968306225:u_suctty=ttyp2:u_unsuctty=INET#ip51-76.dialup.wplus.net:u_unsuclog
#951854562:u_lock@:chkent:
bob
bob:u_name=bob:u_id#5678:u_pwd=wccUzROf9MGKs:u_oldcrypt#0:u_lock@:chkent:
system3 has no such file named /var/tcb/files/file. The
convauth/convuser tools seems to be the correct tools to fix this
problem, but they revert ther user to the uid entry in the auth.db and
not the password file, that is... they change the edauth info to bob
1234 instead of bob 5678. At this point the password file is out of
sync and authck will say so.
system3 and system4 show signs of where the old uid 1234 is coming from.
Unfortunately, system5 still reports 1234, but it is not found in the
system3 place, or the system4 place, this means that system4 may not be
reading it from this 'file' as stated above, but instead from the same
misterious place that system5 is reading it from.
The systems are not using NIS or any other account or directory system.
We simply make accounts on all of them when we need an account. We are
not running a caching daemon such as nscd. All the systems have been
rebooted since the account change and the problem persists. I really
wish I knew where that older uid was coming from.
Can anyone give me pointers or help?
Thanks,
-- Jay R. Wren Systems Programmer Oakland University Rochester, MI
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:44 EDT