Date: Sun, 19 Apr 1998 21:33:12 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: allenc@verinet.com (allen campbell) Cc: hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. Message-ID: <199804192133.OAA14057@usr08.primenet.com> In-Reply-To: <199804191024.EAA10069@const.> from "allen campbell" at Apr 19, 98 04:24:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804192133.OAA14057>