Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!seismo!lll-lcc!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: File System Kudzu
Message-ID: <15917@sun.uucp>
Date: Tue, 31-Mar-87 05:46:33 EST
Article-I.D.: sun.15917
Posted: Tue Mar 31 05:46:33 1987
Date-Received: Thu, 2-Apr-87 01:13:27 EST
References: <4888@brl-adm.ARPA> <14909@sun.uucp> <708@mcgill-vision.UUCP> <328@mtxinu.UUCP>
Sender: news@sun.uucp
Lines: 61

> >Yes.  But is it necessary to provide a *portable* way to write
> >applications to change it?
> 
> Yes, it is.

Necessary to whom?  The number of applications that update the password file
is small.  Those applications don't *have* to be written in a
portable fashion; you can use #ifdefs for UNIX, VMS, etc. if you
want.

> I don't see how specifying a procedural interface to the password file
> (which I expect would do the job) that is complete - i.e. includes routines
> for writing the file as well as reading it - limits the number of
> implementations.  It does make them somewhat more complex, but it
> also makes them more robust.

Specifying a procedural interface to the password file isn't the
problem.  Specifying one that works on *all* POSIX-conforming
systems, regardless of what OS they began life as, is.

Consider an OS that stores more data in its moral equivalent of the
password file than UNIX does.  "getpwent" and company don't cause
problems; you just throw the extra data away.  A routine to change a
record might even be doable; you don't modify the fields that aren't
in the POSIX "struct pwd" (although this reduces the *usefulness* of
this interface - you may not want to use the nominally portable
password file updater, since it won't let you change all the fields).
But what do you do about *adding* records, especially if you *can't*
supply a default for the missing fields?

> What's wrong with putpwent(), and others like it?

"putpwent" is, at best, only a small part of a procedural interface
to the password file.  It is just a routine to write out a "struct
pwd" in the form of a UNIX password file entry.  The System V
"passwd" command knows where the password file is, and knows that it
has to write to a *temporary* file using "putpwent" and then rename
the temporary file.

In order to make "putpwent" useful as a semi-portable interface to
the password file, you'd need an "open the password file for writing"
routine that opened a temporary file, and a "close the password file"
routine that did the appropriate rename of the temporary file and
regenerated the DBM database on systems that provided a DBM form.

Even with that, I'm not convinced you could write a program that
anybody using a VMS with a POSIX-conforming interface would care to
use.  If the only systems that this application is interesting on are
UNIX systems, you might as well just gut the standard "passwd"
command and reuse its code - or, lacking source, rewrite it - and not
worry about portability (or put the DBM update code inside "#ifdef
BSD4_3" or something like that).

(Heck, there are even problems with "*get*pwent".  A number of
programs "know" that the password file is a sequential file, and play
tricks to avoid repeated searches of the password file caused by
repeated calls to "getpwuid" or "getpwnam".  However, if the password
file is indexed in any reasonably-efficient fashion - or even in a
moderately inefficient fashion, if it's really big - this is the
wrong thing to do; you're better off using repeated calls to
"getpwuid" or "getpwnam".)