Xref: utzoo comp.unix.internals:2359 comp.unix.admin:1277
Path: utzoo!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals,comp.unix.admin
Subject: Re: Unix security additions
Message-ID: <19111@rpp386.cactus.org>
Date: 18 Mar 91 12:52:27 GMT
References: <1991Mar18.030955.13123@xavax.com>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 45
X-Clever-Slogan: Recycle or Die.

In article <1991Mar18.030955.13123@xavax.com> jat@xavax.com (John Tamplin) writes:
>I am using a SVR3.2.2 system with shadowed passwords, and the interface
>provided is getspent() etc.  After hacking one too many programs to use the
>new library calls to get the password, I decided the best way to solve the
>problem was to have getpwent() look up pw_passwd in the shadow file iff
>euid=root.  This way, programs that are supposed to have access have it in
>the same old fashion, and programs that don't get some nonsense password
>(either ! or x in the implementations I have seen).

This was tried by myself and others.  There are problems (surprised?)
because you have two locations for the information, and clouding the
issue of "where did that password come from?" causes you to not know
where to put it back to.  It also eats your performance for lunch if
you do more than one or two getpwent() calls.

In the first case, you make a call to getpwnam(), say, to get the
password so your nifty system administration utility can modify it
and put it back - let's call that utility "chfn", which runs setuid
root so it can write the password file.  It does the getpwnam(),
gets the password out of the shadow file (by virtue of running
euid=0) then what?  write it back, but where?  If you do the putpwent()
you will have exported the encrypted password from the shadow file
to the password file.

In the second case, imagine your nifty system utility, call it
finger, reads the password file for a bunch of users.  Each call to
getpwent() implies a call to getspent() (because you invoked finger
as root), and each call to getpwnam() calls getpwent() repeatedly
because that's how it reads the password file.  Remembering that
getspent() is a linear search over a text file, you suddenly realize
that you now have finger() with O(N**2) or so.  DBM-ified password
files would be real handy right about now, but did AT&T give them
to you?

The best solution seems to be to use update the code to use the
correct interface.

>Maybe one of these days I will get around to actually writing this.

Be careful out there ...
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.