From owner-freebsd-config Sun Apr 19 14:33:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16268 for freebsd-config-outgoing; Sun, 19 Apr 1998 14:33:54 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16182; Sun, 19 Apr 1998 21:33:24 GMT (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA18152; Sun, 19 Apr 1998 14:33:18 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd018111; Sun Apr 19 14:33:15 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA14057; Sun, 19 Apr 1998 14:33:12 -0700 (MST) From: Terry Lambert Message-Id: <199804192133.OAA14057@usr08.primenet.com> Subject: Re: Discussion : Using DHCP to obtain configuration. To: allenc@verinet.com (allen campbell) Date: Sun, 19 Apr 1998 21:33:12 +0000 (GMT) Cc: hackers@FreeBSD.ORG, config@FreeBSD.ORG In-Reply-To: <199804191024.EAA10069@const.> from "allen campbell" at Apr 19, 98 04:24:29 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > > Oh.. and while I'm dreaming, how about using portalfs or similar as > > > such: mount /etc with portalfs and have a translator present all of > > > the data from the database in traditional format. > > > > This is a *terrifically* cool idea! > > This simply obsoletes any idea to-date that I know of for supporting > the legacy system. [ ... ] > Terry, I have followed your advocacy of LDAP (or a similar alternative) > for some time now and I have some questions. OK! Let me point out here that though I think LDAP is the best fit, what we are really talking about is a attribute name/attribute value pair, and whether it's implement with LDAP, ACAP, or as an extenstion to SMTP, it's pretty irrelevent. The wins are independent of the implementation details. > 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 irrelevent. > 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. This skirts serialization issues that would otherwise have to be addressed. Mostly these are concerned with multiple writer issues, but there are also transactioning issues that could be addressed at the protocol level, but not enforcible in the direct access case. There are also issues of security model enforcement if you allow local access via some other method. I think that if there is one access point, this enforces a single security model. You can easily get credentials of the "remote" process over a POSIX domain socket in FreeBSD at this point, so "root" authentication is pretty trivial in the boot stage. You could do the same with the loopback interface; the real issue to deal with here is whether or not you will force the existance of full-blown networking. I think it would be a mistake to *require* IPv4 (for example). At the same time, the BSD IPC model is sockets and/or named pipes, and the underlying implementation is tied to the POSIX domain. Short of rejecting the BSD IPC model in favor of the System V model (a bad idea), I can't see not requiring a formal IPC mechanism of *some* kind. The final argument in favor of a client/server model is "very thin clients". This might include printers, scanners, login servers, and so on, which are not very intelligent on their own, but need the services of a more intelligent device (or would function better with the services of such a device than they would function without). This argument also favors the use of SLP (Service Location Protocol), ala the RFC (see http://www.srvloc.org ) after DHCP or 10/8 address configuration to locate such things as document stores (where a FAX machine that isn't a printer, for example) could store incoming documents. > 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? Well, I addressed a little of this above. 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. 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. Together, these models appear to address the rest of your issues for coupling of the security model. 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. For example, you'd need something like this to hold an ACL reference if you wanted to let non-root user manage who had accounts, etc.. 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message