~/.login_conf mechanism is flawed

[Janne Snabb]

On Fri, 13 Aug 2010, jhell wrote:

> I have been using a ~/.login_conf without generating the
> ~/.login_conf.db through the use of cap_mkdb(1) for quite some time. So
> on that, is it really necessary to look for that .db file at all since
> ~/.login_conf works without it...

This change would require some API changes or changing the way some
things work. The relevant generic *cap interface in lib/libc/gen/getcap.c
uses the .db files unconditionally instead of text files if they
exist. This is used for login capabilities, terminal capabilities
and some other things. Do we need a DB backend for these things,
is it unfeasible to just always parse the text files?

To me it would appear that the system DB storage engine (Berkeley
DB 1.85 with some improvements) should be deprecated and replaced
with something else.

Keith Bostic wrote the following in 2004:

> Nobody supports or maintains the 1.85 or 1.86 releases of
> Berkeley DB, the code base has been ignored for almost a decade.
> (Further, there are serious known problems with the 1.85/1.86
> versions, including some that can only be fixed by modifying the
> on-disk format.)

The following thread also touches the topic of DB 1.85 reliability:

http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024425.html

It appears that the Mozilla project has an improved version of the
hash part of the DB code as they use it as a certificate store. The
code seems to have some changes to make it more robust. It resides
in "dbm" sub-directory of firefox source distribution and here:
http://mxr.mozilla.org/security/source/dbm/ . Importing those
improvements to FreeBSD would make sense if we *must* keep using
the deprecated Berkeley DB code.

Opinions? Is it finally time to switch to something else? Are there
any viable alternatives which provide compatible simple interface,
simple file format and robustness, with a suitable license?

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/