Date: Sat, 14 Aug 2010 12:15:00 +0000 (UTC) From: Janne Snabb <snabb@epipe.com> To: jhell <jhell@dataix.net> Cc: freebsd-security@freebsd.org Subject: Re: ~/.login_conf mechanism is flawed Message-ID: <alpine.BSF.2.00.1008141058490.96753@tiktik.epipe.com> In-Reply-To: <4C64D1EF.6030508@dataix.net> References: <alpine.BSF.2.00.1008100841350.96753@tiktik.epipe.com> <alpine.BSF.2.00.1008101503190.96753@tiktik.epipe.com> <201008121302.o7CD2BJv044208@lava.sentex.ca> <alpine.BSF.2.00.1008121828360.96753@tiktik.epipe.com> <4C64D1EF.6030508@dataix.net>
index | next in thread | previous in thread | raw e-mail
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@epipe.com - http://epipe.com/home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1008141058490.96753>