Bugs in GDBM v1.8.0

[John F Sandhoff]

Thank you to Phil Nelson for creating and Jason Downs for maintaining the
gdbm package. We have used it here since around 1994 (always v 1.7.3),
and gdbm files now control many aspects of our daily operations.

I recently noticed the availability of version 1.8.0 and tested a, err,
'discrepency' that is in 1.7.3. Performing a data recorganization
(gdbm_reorganize() call) in reality creates a new file and renames it.

This action has two potentially serious ramifications. First, a user
cannot reorganize a file unless he is the owner (or the file is in a public
writable directory), even if the file is defined as public/write. Much worse,
if the file IS public, performing a reorganize will RESET the protection code
to the calling user's default umask. So a public database will suddenly
become private! (This is what bit us). And if an SUID program (or the root
account) does the reorg, the file ownership suddenly changes to root!

Another oft-overlooked effect of a simple copy-and-rename has to do with
chasing symbolic links. Say I have an actual database in /data/stuff.gdbf
and I have established a symbolic link of /etc/stuff to point to it.
Ater performing a reorganization of /etc/stuff, I end up with TWO totally
unique databases, one in /data/stuff.gdbf and a fresh, reorganized version
in /etc/stuff. If some programs use the symlink name and others use the
actual name, things get real messy real quick.

I've written code to handle similar issues when they occurred in local
programs here. You're welcome to it, but it isn't pretty (while I can
hack my way thru K&R C, a fluent programming artist I'm not!) and I'm
certain your expertise would embarrass my brutish attempts. But I make
the offer anyway..

==
There is another discrepency with file open modes (gdbmopen.c, lines
126 thru 147). I believe that 'case GDBM_OPENMASK' should actually
be 'case GDBM_WRITER'. As it is, if the specified database file does
not exist and an open call with GDBM_WRITER is issued, I believe the
proper behavior is to return an error but unfortunately a new file is
created. (I believe a new file should be created only if the parameter
is GDBM_WRCREAT or GDBM_NEWDB).

Additionally, since GDBM_OPENMASK defines 8 possible open states and
only 4 are defined, it would seem that the 'default' action (that is,
what to do when the specified mode is not one of the 4 defined ones)
should be an error state rather than the present code, which in reality
is 'GDBM_WRCREATE'. But this default action may be intentional. In
fact, the dafault action is why GDBM_WRITER works at all right now..

==
In the man page (gdbm.3), note that the word 'added' appears twice
in a row (lines 286,287):

For the last three (writers of the database) the following may be added
added to \fIread_write\fR by bitwise or:

==

Please don't construe these reported issues to in any way lessen our
appreciation for your outstanding package. As I say, we have relied on
it for 7 years now, it has always served me well and I expect to continue
developing with it.

Thank you,

-- John

      John F Sandhoff, University Network Support
        California State University, Sacramento
          address@hidden