From owner-freebsd-config Mon Apr 20 02:48:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA19383 for freebsd-config-outgoing; Mon, 20 Apr 1998 02:48:51 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (algae19.verinet.com [199.45.181.115]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19362; Mon, 20 Apr 1998 09:48:44 GMT (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id DAA10086; Mon, 20 Apr 1998 03:48:42 -0600 (MDT) (envelope-from allenc) Date: Mon, 20 Apr 1998 03:48:42 -0600 (MDT) From: allen campbell Message-Id: <199804200948.DAA10086@const.> To: allenc@verinet.com, tlambert@primenet.com Subject: Re: Discussion : Using DHCP to obtain configuration. Cc: config@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199804192133.OAA14057@usr08.primenet.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > > How do you address an assertion which says dependency on a database > > reduces robustness because of, for instance, database 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? > > I dispute that there is a significant compromise. > > There *is* a potential compromise. Opponents of using a database > design point to partial corruption equalling partial recoverability > in the flat file. > > I would point out to this position that the flat files use the > underlying file system, which has the same semantics as those > that have been proposed for the user space code. > > The assumption here seems to be that you can't build a robust, user > space transactioning system on top of a robust, kernel space > transactioning system. > > It's pretty easy to prove this assumption wrong from a technical > perspective. We can take the example of pwd_mkdb, the program > that synchronizes the passwd/pwd.db files. It has exactly the same > issues to deal with. > > In fact, pwd_mkdb is a rather nifty example, because it shows us > a feature that we can't get anywhere else: schema enforcement. If > the proposed change would render the database inconsistent, the > change is refused. > > The compromise lies in the non-robustness assumption; it not real, > because it's silly to assume that people who *can't* write robust > user space code *can* write robust kernel space code. It's pretty > much binary: they can or the can't, and the user/kernel qualification > is irrelevant. > I meant the question in regard to database integrity as opposed to schema data consistency. My ambiguity. My own experience with SQL database systems leads me to agree with you. A robust file system supporting a proven transaction engine makes for very solid system, even in the face of severe conditions such as power failure or inadequate resources. A database system also presents good opportunities for safeguards, such as replication and remote fail-over. The paranoid can make use of the configuration portal file system (configfs?) to squirrel away whatever they value most. :) > > > 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? 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? > > I would prefer the client/server design. > > This simplifies the local database access by making it the same as > the remote database access. I was thinking smaller because my interest in this is motivated by the need for a database which is up-gradable via automation, and to provide an abstraction layer against which multiple user interface tools could be authored. By themselves, these goals don't benefit much from a true transaction engine. As Mike described with his Romeo and Juliet model, client/server design is called for, but the minimalist in me notes that a server in this case does not have to be an actual daemon. Clearly there are goals beyond these that do benefit from a transaction engine and I agree that this is best. > If you have followed the SMBFS discussions in the past, the rest > can be very effectively handled through a credential management > interface attached to the login session. > > The most convenient place to put this seems, to me, to be in a UNIX > session manager. All credential requests from the kernel to a process > would be indirected through the session manager process, which could > choose to answer the requests on the user's behalf. Does anything similar to this currently exist that could be exploited for this need? I see your model is correct, but it is also a rather large cathedral. I agree (as you point out below) it is not required initially. > This leads to three models: > > 1) User query, where the session manager butts in and asks the > user for the credential. This is best suited to X and to > the local console, and such other devices as could refresh > the screen transparently without the application having to > know the query has taken place. > > 2) Operation time query. For example, the mount system call > could return ENEEDAUTH, and the mount command could, if > isatty(fileno(stdout)) was true, interrogate the user for > a password. > > 3) Preload, where the credential information is preloaded by > the user before the operation is attempted. This is less > useful interactively, but would allow a "password cache" > type facility. I envision something like a line mode 'registry' editor (configsh?) which would allow appropriate access to go unchallenged after authentication. In this case, 'Preload' would be very useful interactively, as the operator moved among domains in the hierarchy. The session manager would attempt to answer each challenge on behalf of configsh as the operator performed administration tasks. > It wouldn't be necessary to require a session manager initially; one > is only required when you start trying to do tricky stuff that relies > on you already having the associated infrastructure. Even if it only provides a simple security mechanism, it would probably be best if it existed from the start. > I personally dislike the idea of splitting administrative control > into functional domains (in that direction lies SCO ODT and UNIX ES), > but I agree that it shouldn't be architected against, in case someone > else wants to implement it for some strange reason. Somehow, all the domains eventually aggregate onto one person anyhow, whatever the strange reason. :) Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message