relaunchd: a portable clone of launchd

[Mark Heily]

On Wed, Jan 13, 2016 at 2:05 AM, Hubbard Jordan <jkh at ixsystems.com> wrote:
>
>  All of the ACLs in the world won’t help you to create an extensible security trailer that identifies multiple clients of a single server in a unique way (pid/uid/gid is practically useless for this).

Do you have any specific examples of how an "extensible security
trailer" would be used? Even better, can you demonstrate that Mach is
the only way to implement this concept?

Generally speaking, libipc is extensible because it is an abstraction
layer and the wire protocol is not exposed directly to clients or
servers. I could offer the example of extending the system to support
MAC labels: if there was a requirement for the server to be able to
check the MAC label of a client, one could extend the API to add a
function named ipc_client_get_mac_label() that would do the needful
under the covers.

>> Using the filesystem as a way to coordinate activity is a perfectly
>> natural thing to do, and only has a disadvantage in a small corner case
>> (where the system is in the process of booting up and the filesystem
>> is not mounted).
>
> That’s actually not a corner case on the software appliances we’ve been creating lately.  That’s the usual case. :)   You start out with a bootstrap MFS and then selectively mount ZFS datasets and such on top of various locations that would like to have more storage (like /var/tmp or /var/db).  This makes locating your Unix domain sockets a bit tricky.  Again, this is not just hypothetical - we’ve run into multiple problems where we wound up covering up our own mongodb / syslog sockets and hilarity ensued until we realized the problem and sorted it out.
>

Well, unless you have modified MongoDB to use Mach instead of
Unix-domain sockets, I think we are talking about two different
problems. Mach is not going to solve the problem you are talking
about.

My original comment was in the context of comparing libipc (which is
socket-based) to Mach IPC. There is a legitimate advantage to Mach IPC
in that it is available very early in the boot process, before the
root filesystem is mounted. Once the root filesystem is mounted, the
libipc service discovery directory will live under /var/run/ipc, which
probably will never be covered up by another filesystem as you
describe.

OTOH, if everything were rewritten to take advantage of libipc for
service discovery, rather than each program using their own ad-hoc
sockets in /var/wherever, the kind of problem you are talking about
goes away. That's why I'm making libipc portable, in the hope that it
becomes ubiquitous.

> Again, I clearly can’t convince you otherwise, but a service discovery mechanism built-in to the kernel is awesome and to say “you don’t need it” is a bit like someone telling you that you don’t need to make whatever amount of money you’re making but should be happy working as a night clerk at 7-11.  Who is anyone to make that kind of assertion without background? :)
>

I never said "you don't need it". In fact, I've written libipc to
provide a service discovery mechanism built-in to the kernel. It uses
the standard open(2) syscall instead of Mach, but the intent is
similar.

>> Not true. You have to provide your own semantics for finding
>> the message boundaries, but it is totally possible to send messages
>> across Unix-domain sockets.
>
> Of course you can send messages over Unix-domain sockets.  You can send messages using a morse-code key and a Marconi spark-gap transmitter, for that matter, but that doesn’t mean you don’t want something else to take care of that for you.  Mach IPC does, and that’s all I meant on that slide.

If that's what you want, datagram sockets will preserve message
boundaries for you. I selected stream sockets for libipc because I
wanted to the ability to detect when the client exits, and be able to
clean up resources on the server side.

Honestly Jordan, this is such a poor argument you should probably take
it off your slide and focus on more compelling advantages of Mach.

> I dunno, but it sure seems to me like you’re going to such lengths to hate on Mach IPC that you’re willing to essentially argue against architecture, clean abstraction boundaries, and pretty much anything anyone finds valuable in order to hold such a strong position.
>  It’s sort of reminiscent of various arguments I’ve had with assembly bigots that high level languages are just a waste of time and CPU cycles and there’s absolutely nothing worth doing that can’t be done in assembly.  I mean sure, they’re not out-and-out WRONG, but the entire argument seems silly in the extreme.
>

I'm disappointed that you would resort to this level of ad-hominem
attack. I've tried to keep this a purely technical discussion, and I'm
not going to question your personal motives or integrity. Please offer
me the same courtesy.

 - Mark