Thanks to:
Richard Rogers - with the right answer
and Jim Belonis with a good suggestion
The question summary: why am I still seeing instances of no-longer extant
user names when I look at file & directory ownership, and why do the users
with the same numeric IDs have trouble using sudo?
The answer is: the hashed passwd file was out of sync and needed rebuilding
with mkpasswd since I had not used vipw to edit the files. vipw
automatically rebuilds the hashed files. (So if you use vi or emacs or
whatever to edit your password files, even in single user mode where things
can't get altered by more than one person at once, you must also use
mkpasswd to bring the hashed passwd file back into sync with the real one).
The complete original question:
At 05:30 PM 12/20/1999 -0600, Chad Price wrote:
>A while back, I screwed up and created accounts with the wrong names (left
>out the quotes around the gecos info and wound up with capitalized account
>names and so on). Edauth only retired accounts and I wanted to start from
>scratch again. To fix that, I used authconv to convert the password data
>back to the files format, edited it and removed the unwanted accounts, and
>then removed the auth.db file. Then recreated the auth.db files with
>authconv. So far so good. Old history seems to be gone, account names are
>no longer retired, they are gone.
>
>Remaining problem: the account names orignally created seem to retain
>ownership of the directories and appear when (for example) sudo tries to
>allow someone privleges.
>
>Example:
>(1) created a user called Babcook with home directory dbabcook and owned
>by Babcook. This is wrong, and so
>(2) used authconv and removed auth.db file after using edauth to
>remove/retire the account. Removed entry from passwd file.
>(3) removed home directory.
>(4) recreated account with same uid as original. And reconverted to C2 so
>that auth.db is the definitive password database again and is a completely
>new file with no prior history of the Babcook account.
>
>At this point, auth.db has no record of "Babcook" as a valid user name,
>nor does the password file in /etc.
>
>Problem: the directory is shown by ls as being owned by Babcook. When the
>user logs in and attempts to use sudo, sudo forbids it, saying "Babcook
>not in /etc/sudoers file". OK. Add Babcook to sudoers file (but user is
>logged in using dbabcook..) Now error is that the password provided to
>sudo is wrong.
>
>It appears that Babcook was not removed from the system by removing the
>passwd and auth.db entries.
>
>Where else could it be? Or do I simply need to reboot the system? (It's
>been 80 days..) Rebooting is not mentioned in the man pages in connection
>with edauth or convauth.
>
>
>Chad
>
>Chad Price
>Systems Manager, Genetic Sequence Analysis Facility
>University of Nebraska Medical Center
>986495 Nebraska Medical Center
>Omaha, NE 68506-6495
>cprice_at_molbio.unmc.edu
>(402) 559-9527
>(402) 559-4077 (FAX)
>
Chad Price
Systems Manager, Genetic Sequence Analysis Facility
University of Nebraska Medical Center
986495 Nebraska Medical Center
Omaha, NE 68506-6495
cprice_at_molbio.unmc.edu
(402) 559-9527
(402) 559-4077 (FAX)
Received on Tue Dec 21 1999 - 14:10:23 NZDT