Date: Sun, 19 Apr 1998 10:22:15 -0700 From: Mike Smith <mike@smith.net.au> To: allen campbell <allenc@verinet.com> Cc: config@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. Message-ID: <199804191722.KAA01985@antipodes.cdrom.com> In-Reply-To: Your message of "Sun, 19 Apr 1998 04:24:29 MDT." <199804191024.EAA10069@const.>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> How do you address an assertion which says dependency on a database
> reduces robustness because of, for instance, database corruption?
How do you address an assertion which says dependency on configuration
files reduces robustness because of, for instance, file corruption?
> Do you disregard the assertion based on evolutionary necessity
> ('bite the bullet') or do you dispute that there is any significant
> compromise at all?
Corruption can come from at least couple of sources:
- Faulty applications.
- Backing store (filesystem) corruption.
- User error.
In the case of plain text files, application faults are less an issue
(most text editors work OK), but the others remain an issue. With a
database, especially in the early stages, you have to worry more about
the stability of the application(s), but less about the user being able
to nuke things.
By leveraging a known-stable database engine (the Umich LDAP server),
we hope to reduce the application-fault vulnerability profile.
> Does a configuration database imply a client/server design and,
> therefore, a daemon to implement the server, or do you expect that
> a static/shared library would allow the client direct access?
Client/server is highly desirable, but starting the server early enough
to be useful is a bit of a challenge.
> The
> former provides for a very thin client and powerful concurrency
> control (such as signaling registered clients when the hostname
> changes.) The latter has the appeal of not requiring an daemon
> which would be tough to support in minimalist applications. Both
> perhaps?
A read-only client library would have numerous advantages for
minimalist applications, yes.
> Different parts of the configuration hierarchy have different
> security requirements and this will ultimately require close
> integration with the kernel for enforcement, authentication, etc.
> How does that square with a user mode subsystem such as LDAP?
The Umich server supports the use of password-protected ACLs. In
addition, one can use SSL to secure communications with the server.
Combining this with FreeBSD's ability to unequivocally ascertain the
credentials of the process at the other end of an IPC channel, an
end-to-end secure and authenticated pipe can be constructed from a
local application, via a local forwarder to a remote parameter store.
> As a database applications developer, I have learned that there is
> little integration between host system security and database security
> in contemporary SQL database systems.)
The real challenge as we move to a distributed parameter store is to
shift perspective back a little further and see that database security
encompasses the entire network, not just a single host. But you're
right in this case - the system's security model must be incorporated.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-config" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804191722.KAA01985>