Linking against libdb2

[Henry B. Hotz]

The database in question only exists on the Kerberos servers, and  
contains sensitive information.  You shouldn't be running other app's  
on that server in the first place.  In the second place you really  
shouldn't allow other app's access to that database if they are on  
the server.

I can't imagine an independent application that doesn't constitute a  
security hole.  If you are adding functionality to the Kerberos  
service then the nature of that functionality and how to design it  
are what I *think* you should be asking about.

On Mar 19, 2007, at 9:03 AM, krbdev-request at mit.edu wrote:

> Date: Sun, 18 Mar 2007 11:28:47 -0600
> From: Philip Prindeville <philipp at redfish-solutions.com>
> Subject: Re: Linking against libdb2
> To: Ken Raeburn <raeburn at MIT.EDU>
> Cc: krbdev at mit.edu
> Message-ID: <45FD76CF.9050102 at redfish-solutions.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Ken Raeburn wrote:
>> On Mar 17, 2007, at 21:09, Philip Prindeville wrote:
>>
>>> How does one link an application against the plug-in
>>> libdb2?
>>>
>>> In the 1.4.3 RPM, this was fairly straightforward, but
>>> that seems to have changed significantly in 1.5.
>>>
>>
>> If you're referring to the "db2" KDC plugin, the only symbol it
>> exports is a table of (mostly) pointers to functions to be used by
>> the KDC.  The "libdb2" library isn't available any more, as that
>> library is now part of the db2 back end (the only thing we support
>> that uses it), and we don't export its interface symbols.  (I don't
>> think we want to be in the business of supporting it as a generally-
>> used database interface.)
>>
>> Ken
>>
>>
>
> Ok.  Not sure I understand.  Here you have a general
> database that any Kerberized applications could count
> on using... instead of having to conditionally use DBM,
> NDBM, GDBM, etc.
>
> There are certainly worse things than having it be part
> of the general environment.
>
> -Philip

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu