relaunchd: a portable clone of launchd

[Dan Partelly]

> 
> This is generally a bad thing, IMHO. Filesystem permissions are a
> good way to apply security rules to an object, 

It is a good thing to have a hierarchical namespace which do not depend on the filesystem.
Port right are also a good way to apply security rules to objects. 

> Using the filesystem as a way to coordinate activity is a perfectly
> natural thing to do

Why would be so natural ? 

> A machine where the root filesystem is not mounted read/write is
> basically unusable, and the solution is to mount the filesystem ASAP
> before starting any services that rely on IPC.

Yet kernel events of interest may happen  before a filesystem is mounted. 



> If Mach has such a great RPC interface, why do we need to hide it behind
> another abstraction layer like XPC?

The usual reason we build abstractions over other abstractions. Same reason you
created a RPC library. Ask yourself why you created an rpc abstraction on top of unix 
domain sockets, and you will get the answer.


> Monolithic kernels don't use
> message passing, so we aren't missing out on much by not having this
> feature.

This is dogmatic and it misses the point of why kernel endpoints are needed. 
 The situation has nothing to do with monolithic and microkernel  designs. 
It allows any kernel component to pass messages to arbitrary destinations.
It is a generalised mechanism like devd. Good luck generalising that with unix sockets.


> There are some major benefits to
> using sockets, such as the fact that are portable and relatively
> standardized across different Unix implementations (and even Windows).

And why is portability of such a  subsystem relevant ?  Its not like anybody will jump
to port launchd Windows :P Or even Linux. Nobody will care.

>> 
>> Receive messages directly in call to kevent()
>> 
> 
> This is a "nice to have" performance optimization. We can live without it.


Tautology.  We can live without sendfile(2). We can also live without kqueue/kevent(2)
themselves. We could have lived with DOS.


> On 13 Jan 2016, at 05:08, Mark Heily <mark at heily.com> wrote:
> 
> On Tue, Jan 12, 2016 at 10:59 AM, Hubbard Jordan <jkh at ixsystems.com <mailto:jkh at ixsystems.com>> wrote:
>> 
>>> On Jan 12, 2016, at 4:59 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
>>> 
>>> I highly recommend to Google for "Mach IPC sucks" if reader is really interested.
>> 
>> And here we return to the usual trap…
>> 
>> “Mach IPC sucks!”
>> 
>> “OK.  What do you propose that will address all of the same concerns?”
>> 
>> “dbus!”
>> 
>> “*Sigh*.  You haven’t even looked at the two technologies in any depth, have you?  Go read the dbus wikipedia page, at least!  Unix domain sockets underneath, no kernel<->userland communication path, no trusted IPC mechanism, no support for large messages…”
>> 
>> “OK, so something new!!  We should totally create an IPC for the New Millennium!”
>> 
>> “That would be you then?  Where’s your white paper?  Where’s your reference implementation?”
>> 
>> <crickets>
>> 
>> Sorry.  Been there, had this debate, and while it’s always extremely easy to fling poop at an existing mechanism, it turns out it’s so much harder to actually *create an alternative* that this kind of discussion only serves to throw cold water on evolution (“the perfect being the enemy of the good enough”) and the end-result is that evolution does not occur.
>> 
>> 
> 
> You're right in that DBus is not a great solution, and I think we can do
> better.
> 
> I've gone ahead and created a general-purpose IPC library that is a
> plausible alternative to Mach IPC. Here's the code:
> 
>   https://github.com/mheily/libipc <https://github.com/mheily/libipc>
> 
> It is not a bus, and it is not object-oriented. Instead, it tries to
> make calling a remote function as easy and seamless as calling a
> local function. I was planning on hacking on it for a few more weeks
> before announcing it, but it seems very relevant to the discussion
> we are having today.
> 
> It's built on top of Unix-domain sockets, and includes an IDL compiler
> that takes a reasonably simple YAML file and generates the boring
> code that allows programs to do structured IPC without worrying about
> serialization and bootstrapping and all of the underlying protocol
> issues.
> 
> You've raised some objections to Unix-domain sockets, which I'd like
> to respond to.
> I'll quote from the slide in your presentation about Unix-domain sockets:
> 
> ------------------------------------------------------------
> 
>> 
>> 
>> What can Mach ports do that Unix domain sockets can't?
>> 
>> Separate namespace for services (doesn't rely on file system naming or
>> permissions)
>> 
> 
> This is generally a bad thing, IMHO. Filesystem permissions are a
> good way to apply security rules to an object, and they are a highly
> standard and well understood concept. If you need more than the
> traditional user/group/other support, you can supplement this
> with POSIX ACLs.
> 
> 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).
> 
> Right now, there is no need to perform IPC in the early part of the boot
> process. A machine where the root filesystem is not mounted read/write is
> basically unusable, and the solution is to mount the filesystem ASAP
> before starting any services that rely on IPC.
> 
>> 
>> Message boundaries
>> 
> 
> 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.
> 
>> 
>> Kernel as peer
>> 
> 
> This is true, but not there are other ways for userspace to communicate
> with the kernel, such as syscalls and ioctl. Monolithic kernels don't use
> message passing, so we aren't missing out on much by not having this
> feature.
> 
>> 
>> Pre-existing well defined RPC interface
>> 
> 
> If Mach has such a great RPC interface, why do we need to hide it behind
> another abstraction layer like XPC? The existence of a thing is not
> necessarily an argument for it being the right tool for the job.
> 
>> 
>> Receive messages directly in call to kevent()
>> 
> 
> This is a "nice to have" performance optimization. We can live without it.
> 
>> 
>> OOL (out of line) messages (arbitrarily sized with zero copy for large messages)
>> 
> 
> You can do zero-copy over Unix-domain sockets by sending a file descriptor
> across the socket that is backed by an anonymous region of memory
> created with mmap(2).
> 
> To get the out-of-line behavior, all you need are two Unix-domain
> sockets; one acting
> as the control channel, and the other as the data channel.
> 
>> 
>> Port send rights - can only send to a port for which the process has explicitly
>> received the right to send
>> 
> 
> Unix-domain sockets have file permissions that control access. This is
> functionally
> equivalent to "port send rights", right?
> 
>> 
>> Provenance - Yes, PROVENANCE, receiver can have the kernel append an audit
>> trailer containing full set of credentials of sender
>> 
> 
> Unix-domain sockets allow you retrieve UID, GID, and PID of the client
> process. Unless you mean something different by "PROVENANCE", this
> is all the information you really need to make security decisions in
> the current Unix security model.
> 
> ------------------------------------------------------------
> 
> So the TL;DR is that you can use Unix-domain sockets to do
> most of what Mach IPC provides. There are some major benefits to
> using sockets, such as the fact that are portable and relatively
> standardized across different Unix implementations (and even Windows).
> I think if you do a cost-benefit analysis between Mach and sockets,
> sockets win.
> 
> Anyway, I'm planning to implement IPC in relaunchd using libipc,
> and relaunchd will be able to create the IPC service and launch
> the job "on demand" whenever a client attempts to connect to it.
> 
> We've taken up a lot of airtime on this mailing list, so I invite
> anyone who is interested in IPC to join me on the libipc mailing
> list to discuss this further:
> 
>  https://groups.google.com/d/forum/libipc-devel <https://groups.google.com/d/forum/libipc-devel>
> _______________________________________________
> freebsd-hackers at freebsd.org <mailto:freebsd-hackers at freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org <mailto:freebsd-hackers-unsubscribe at freebsd.org>"