Date: Thu, 14 Jan 2016 08:40:47 -0500 From: Mark Heily <mark@heily.com> To: Hubbard Jordan <jkh@ixsystems.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <CAGfo=8mQ3xRck_sGr%2B0g%2B9mfD8bPSauMoPK-qk-ns3-qzbtn7A@mail.gmail.com> In-Reply-To: <66E766F4-66D5-41E1-B6E7-18E218B3711F@ixsystems.com> References: <5687D3A9.5050400@NTLWorld.com> <CAGfo=8kXzNVKy9gx0jkME4iRRyrgrsfpPnW3nYrZC0gysapPcg@mail.gmail.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <alpine.BSF.2.20.1601081020270.34827@nog2.angryox.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <E85C42D4-963B-4632-9182-E591A80D1306@rdsor.ro> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> <CAGfo=8mBhCPUH8cxmo2z_GDUfknojSnyUTyBC6Wzk=BR=oA%2Big@mail.gmail.com> <66E766F4-66D5-41E1-B6E7-18E218B3711F@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 13, 2016 at 2:05 AM, Hubbard Jordan <jkh@ixsystems.com> wrote: > > All of the ACLs in the world won=E2=80=99t help you to create an extensi= ble 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=E2=80=99s actually not a corner case on the software appliances we= =E2=80=99ve been creating lately. That=E2=80=99s 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=E2=80=99ve run into mult= iple problems where we wound up covering up our own mongodb / syslog socket= s 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=E2=80=99t convince you otherwise, but a service disc= overy mechanism built-in to the kernel is awesome and to say =E2=80=9Cyou d= on=E2=80=99t need it=E2=80=9D is a bit like someone telling you that you do= n=E2=80=99t need to make whatever amount of money you=E2=80=99re making but= should be happy working as a night clerk at 7-11. Who is anyone to make t= hat 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 m= essages using a morse-code key and a Marconi spark-gap transmitter, for tha= t matter, but that doesn=E2=80=99t mean you don=E2=80=99t want something el= se to take care of that for you. Mach IPC does, and that=E2=80=99s all I m= eant 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=E2=80=99re going to such length= s to hate on Mach IPC that you=E2=80=99re willing to essentially argue agai= nst architecture, clean abstraction boundaries, and pretty much anything an= yone finds valuable in order to hold such a strong position. > It=E2=80=99s sort of reminiscent of various arguments I=E2=80=99ve had w= ith assembly bigots that high level languages are just a waste of time and = CPU cycles and there=E2=80=99s absolutely nothing worth doing that can=E2= =80=99t be done in assembly. I mean sure, they=E2=80=99re 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGfo=8mQ3xRck_sGr%2B0g%2B9mfD8bPSauMoPK-qk-ns3-qzbtn7A>