DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: dynamic /bin /sbin
On Fri, 25 Jul 2003, Bosko Milekic wrote:
> Personally, I myself prefer the so-called "IPC" approach to doing
> nsswitch. Namely, a daemon which is itself possibly
> dynamically-linked and which may do caching, and where the libc code
> talks to the daemon and has a local 'fallback' method.
>
> FWIW, some guys at RSU (the russian RSU, Rostov State University)
> claim to have some daemon code which puts us on the path towards
> exactly the above-described model. This model does not require a
> dynamically-linked root. I think that OS X does something along those
> lines, too.
You are correct that, in general, OS X isolates services relating to
authentication and directory services in separate tasks (processes) and
uses IPC to communicate with them. However, OS X also is entirely
dynamically linked, with (I believe) the exception of init. The
authentication and authorization services in OS X are moving fairly
rapidly away from being entirely centered around NetInfo to being centered
around a set of well-defined Service APIs exposed via Mach IPC. There
seem to be a few layers to addressing these problems correctly: define
APIs that provide sufficient generality to do what you want, then
determine the place the code executes by virtue of your more general
system architecture and requirements. A reasonably written API on the
front-end should support whatever implementations you need on the back.
And ideally, you shouldn't have to rewrite your applications when you
change your mind.
In a system oriented more around light-weight IPC, isolating those
components makes a lot of sense to me. However, one of the big problems I
keep bumping into in OS X, from a security perspective, is a lack of a
trustworthy IPC namespace -- this will likely keep biting them in various
forms. Given the discussion here of improving the IPC infrastructure for
a more message-passing oriented system, I hope the benefits of a
hierarchal and security-aware IPC namespace won't be lost. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@xxxxxxxxxxxxxxxxx Network Associates Laboratories
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]