From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24046 invoked from network); 2 Aug 2021 02:33:25 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2021 02:33:25 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5F41D9CA64; Mon, 2 Aug 2021 12:33:23 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 14EAB9CA63; Mon, 2 Aug 2021 12:33:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=iitbombay-org.20150623.gappssmtp.com header.i=@iitbombay-org.20150623.gappssmtp.com header.b="zc8+kF4T"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 762039CA63; Mon, 2 Aug 2021 12:32:59 +1000 (AEST) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by minnie.tuhs.org (Postfix) with ESMTPS id 2A4BA9CA60 for ; Mon, 2 Aug 2021 12:32:58 +1000 (AEST) Received: by mail-qt1-f176.google.com with SMTP id w10so10769895qtj.3 for ; Sun, 01 Aug 2021 19:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ln+5yLRR73MoXtqlFsFtNqflBzPIwIadQCq+xloQ7kU=; b=zc8+kF4T4R0eKHlpNjhSDg71GSjCyyhIY+xCDQ2g/9EJnjMkhNoN3qpvi7ECGdfb+Z 4xbg9QgD2p4nPU8eaD7Dn84/A3k9r+UHjHnQur8gXHBhKxgtyWmO/u85jNgVYPyLYI9w wLEJebIJXADlrqpA1Oq0bY3/FNEFXaieKV3Kvd0N1YXqgxe0UWj5WDftTjpR6mhuAnxT dmyt359oo7fZOxEYBo0BZqsY3rsZiAW3J2u+aLGKqiHt/4c5+fdXxjtNbgcU2sAmE7aa wPnGiMYSykOL1ey3IDuAshCgT6V9nLKN6uz0UCRqkvDSMhbZuH3HOhIN+xvvC9gJdShs j5Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ln+5yLRR73MoXtqlFsFtNqflBzPIwIadQCq+xloQ7kU=; b=hoOMeudDD8zKRQR5W/hfELEQfpAwa97bDCYk1+bvaOqtlWXd4bMtQKwljwDsGLVpUg bhN5DfUqAtolAjATP5mrPXgTggoMxhrK3H5oVGDs3Mxm38rSGA3FJ3NwqyJWfQBMIdgl O3v2VmA/lYaDBvq2NC7j1s567g2rmEq2NF+5ZEgT48PROney3slm28EkcEHm4DDvTT3c xXptYbOkrmlKTLA9WoZV7QsENnBZCO/Y7VvKw3+iXputjILEQMVTduic+fZZwwjuJXWE mcch4vYHmzJBgZNgAbV7qfOBIxc5ZhxUFhbmvF5gKfqA1LJnmbIMAEviVLTpH0ZJjgfO izUA== X-Gm-Message-State: AOAM531NkKYF+JCan5LMKTSaA/Ksbl6hwuIofEBQRGpCfKDIRowpo23K RxZmT3lySI2xk5+Go20BSjUcAQ== X-Google-Smtp-Source: ABdhPJxC8bNGFVYwvt3Xb+GbsGCF+iVcg3vwv8cRTuH8X/FsKdBT29yYiJxEqX5Vpoyvxhtb4FKH2w== X-Received: by 2002:ac8:6e86:: with SMTP id c6mr12670137qtv.138.1627871577272; Sun, 01 Aug 2021 19:32:57 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id j198sm5112419qke.120.2021.08.01.19.32.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Aug 2021 19:32:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Bakul Shah In-Reply-To: Date: Sun, 1 Aug 2021 19:32:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> To: Theodore Ts'o X-Mailer: Apple Mail (2.3654.120.0.1.13) Subject: Re: [TUHS] Systematic approach to command-line interfaces X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Aug 1, 2021, at 6:05 PM, Theodore Ts'o wrote: >=20 > On Sun, Aug 01, 2021 at 06:13:18PM -0600, Andrew Warkentin wrote: >> There's a third kind of primitive that is superior to either spawn() >> or fork() IMO, specifically one that creates a completely empty child >> process and returns a context that lets the parent set up the child's >> state using normal APIs. >=20 > I've seen this argument a number of times, but what's never been clear > to me is what *would* the "normal APIs" be which would allow a parent > to set up the child's state? How would that be accomplished? Lots of > new system calls? Magic files in /proc//XXX which get > manipulated somehow? (How, exactly, does one affect the child's > memory map via magic read/write calls to /proc//XXX.... How > about environment variables, etc.) >=20 > And what are the access rights by which a process gets to reach out > and touch another process's environment? Is it only allowed only for > child processes? And is it only allowed before the child starts > running? What if the child process is going to be running a setuid or > setgid executable? =46rom the "KeyKOS Nanokernel Architecture" (1992) paper: ---- KeyKOS processes are created by building a segment that will become the program address space, obtaining a fresh domain, and inserting the segment key in the domain's address slot. The domain is created in the waiting state, which means that it is waiting for a message. A threads paradigm can be supported by having two or more domains share a common address space segment. Because domain initialization is such a common operation, KeyKOS provides a mechanism to generate "prepackaged" domains. A factory is an entity that constructs other domains. Every factory creates a particular type of domain. For example, the queue factory creates domains that provide queuing services. An important aspect of factories is the ability of the client to determine their trustworthiness. It is possible for a client to determine whether an object created by a factory is secure. ---- This paper also talks about their attempt to emulate Unix on top. http://css.csail.mit.edu/6.858/2009/readings/keykos.pdf=