From owner-freebsd-hackers@freebsd.org Thu Jan 14 13:40:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41C4AA813A3 for ; Thu, 14 Jan 2016 13:40:49 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1205F1724 for ; Thu, 14 Jan 2016 13:40:48 +0000 (UTC) (envelope-from mark@heily.com) Received: by mail-io0-x230.google.com with SMTP id q21so452853840iod.0 for ; Thu, 14 Jan 2016 05:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JfckE2xv5EUekELgvnTkSLi/gdF0bagHXsDLhGWzYSM=; b=fjpwUzQVtHx345AC4JN9zCCSakO+x/Yb4ITbJqgnywqaj6bOjI5VKuiuo7b/UpkJ8o Ze1jxgGbVxNPAJc0wI3OyiWZu0f/Plk4YFefUU1md396fQjpVq8duMnd87jEg9IDXxhK 9zn7lvGLHUR3KZpcN6uvdQBYMM9cFjiGiMz8nYz+SxbuaBu9DS4d+z2pyt9a2x7KwPns E0wVEv7kbbkGGKr2dgMLm7tJjg0JMYcsbMzczdqukUD28W4JMDVzKlY0Tk7GSu8co/f/ a4+Ls8oJ8s3jfpI0VVTCGFN0YQpdytL9XdaiPddVpG3bcReGSuIPi8/mDQZExGWU/rpw O4NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JfckE2xv5EUekELgvnTkSLi/gdF0bagHXsDLhGWzYSM=; b=bhhMWlbUW1IHkURy34fbKwtbCUA1nFk+yN+MmQ6kYXB1xOpPe/XRt+vpxVO+BoVi3M UWV8goE7dYcUL4XJ3yh2MT0WZolwrDzPbgECYK/kwGGHavnWA7o4IUXl9GeAwKDSfVmn WnzxgVWymKN93yLWdDI5a++e4g70qZWjJmS+oqsLgSZh8vRrhCX+n7DrzLkZGsI5yVDg HAOGCd8dHLs+qkOeREKxp1aUvWYCqzwgUQMkfEMCEHl1gVtKBx7MQVNd/2srqR7fpQ3d AfSxKSt4/PsP+wXFMK8DXZT9wc0qdNmDY2NXrcI0UKuu//qPJY8gWp/ntIjpiLS90g7B 6JUw== X-Gm-Message-State: ALoCoQn+PGEffGRq5IFbj6X7p4nniQf3vD1M3HjsS/bJ4uYAAHFDRdDRNd22MZ8an0Plv6jvSS0OuIcJrfdmqanXctdI8Vwt8g== MIME-Version: 1.0 X-Received: by 10.107.43.138 with SMTP id r132mr5397826ior.7.1452778848035; Thu, 14 Jan 2016 05:40:48 -0800 (PST) Received: by 10.79.34.196 with HTTP; Thu, 14 Jan 2016 05:40:47 -0800 (PST) X-Originating-IP: [71.70.175.250] In-Reply-To: <66E766F4-66D5-41E1-B6E7-18E218B3711F@ixsystems.com> References: <5687D3A9.5050400@NTLWorld.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> <66E766F4-66D5-41E1-B6E7-18E218B3711F@ixsystems.com> Date: Thu, 14 Jan 2016 08:40:47 -0500 Message-ID: Subject: Re: relaunchd: a portable clone of launchd From: Mark Heily To: Hubbard Jordan Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 13:40:49 -0000 On Wed, Jan 13, 2016 at 2:05 AM, Hubbard Jordan 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