From owner-freebsd-hackers  Fri Oct 31 19:42:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA26291
          for hackers-outgoing; Fri, 31 Oct 1997 19:42:06 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26281
          for <freebsd-hackers@freebsd.org>; Fri, 31 Oct 1997 19:41:52 -0800 (PST)
          (envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
	id 0xRUP9-0002xo-00; Fri, 31 Oct 1997 19:39:19 -0800
Date: Fri, 31 Oct 1997 19:39:04 -0800 (PST)
From: Tom <tom@sdf.com>
To: Simon Shapiro <Shimon@i-Connect.Net>
cc: "Bryn Wm. Moslow" <bryn@nwlink.com>, freebsd-hackers@freebsd.org,
        Dave Chapeskie <dchapes@golden.net>
Subject: Re: Password file builds
In-Reply-To: <XFMail.971031183012.Shimon@i-Connect.Net>
Message-ID: <Pine.BSF.3.95q.971031193302.11298C-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Fri, 31 Oct 1997, Simon Shapiro wrote:

...
> >    The biggest problem with this is, that there are no tools to fix or
> >  verify db files.  If the /etc/pwd.db or /etc/spwd.db becomes damaged,
> >  you're screwed.
> 
> Same thing if the filesystem gets corrupted.  Both are a complex, not
> easily human-readable structures that contain complex data.  A file system,
> in this view is a simple, single-indexed heirarchial database (almost
> network, but not quite).  In well written software, the risk is similar,
> except that a db file is sompler to backup.

  True, but filesystems have "fsck".  We don't have a "dbck".  I wish
there was one.

> >    Also, there are locking issue with in place updates of db files.  Do
> >  the
> >  pw routines in libc even do locking?  I don't think so.  What happens if
> >  someone calls getpwnam() at the while someone else is writing a new
> >  entry
> >  into the database?  Bang, you're dead.
> 
> Now, these are legitimate concerns.

  Yes, the old rebuild and rename process is atomic, safe, and easy to
implement, but slow.


> Sincerely Yours, 
> 
> Simon Shapiro                                                 Atlas Telecom
> Senior Architect         14355 SW Allen Blvd., Suite 130 Beaverton OR 97005
> Shimon@i-Connect.Net                                  Voice:   503.799.2313
> 
> 

Tom