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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21523 invoked from network); 2 Aug 2021 02:11:21 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2021 02:11:21 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 73C749CA96; Mon, 2 Aug 2021 12:11:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C30299CA63; Mon, 2 Aug 2021 12:10:51 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XssuvF8j"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 3C5749CA63; Mon, 2 Aug 2021 12:10:49 +1000 (AEST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by minnie.tuhs.org (Postfix) with ESMTPS id 7ACF89CA60 for ; Mon, 2 Aug 2021 12:10:48 +1000 (AEST) Received: by mail-lf1-f46.google.com with SMTP id h14so30876901lfv.7 for ; Sun, 01 Aug 2021 19:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=I1m9z0gkxp8f9SOz5pIzUTIxEFlYDaXyEiQS4IeQdFQ=; b=XssuvF8jhN9rSQhZCBJjR7wnBcKsgfTtPBGcI2WE4iaDEaLRz+/SkbcvEc+HPfz4K8 fu2oaucs6ff1S6RB8LF4BjLMx4tQZvQXVdMP6PNumgOgLJqWajchmgNDfyYXrj5ppHjJ AUIGpI7NQviemgskHPFLFI+OELpmPiOWkrATf/4H75hFe82mCKumCLk/p26vsXox3mDp jXjDgxS+8owZYkUDE4PsVcWiszuz+vGuT3da88rG0x349R2zg8XrhJX4+FyvOT4NXWZK WTwxfnlHtDM/vm3nsNzHvp5pyR732TQir3hE4USNyrUghz16JtYfRw6p6qUgG5JHveCb G3BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=I1m9z0gkxp8f9SOz5pIzUTIxEFlYDaXyEiQS4IeQdFQ=; b=g051FIA5PquEObtZ0UtzSZrx+RPlUgH9Jk0g0G82PLwz9tp+sP+yRNKDLEghG5z6pg dvJYpiGlJX6RJkfqg26+7Gs3aAnUQrRedWh+Sa7eLf9z3kWsl+VqKc6hClZ6z0/G+i0C A9emr2DxLEl1wPQVOuO3zukIVYeMniy87mOqoIUIJFTSVtckrN2SiH2rXVD8EHQLSG8P +YDPvwkm6QzA/WRwsYd2swK1PwBx4QZF/tRa5aBeKIMR997JgCKZofgj8M9W1ZOC1hiV 6ofhDA8xmIEkN857cETf1zqOAblsGrs4QQHOy4wvUgyElogfEJ22JmQUDfy6Io2v6JBa fgkg== X-Gm-Message-State: AOAM530sxZqOZoPVraPZp0Qap5m9KMfiX4vhbCSN6DmqnDfuM2IbNCXw S3R00n6VkvsPJFfzSw2LCLE7ktQu04DKQd3r8U8jdSk9wMo= X-Google-Smtp-Source: ABdhPJybjvcNHqw211wZsF7EJB6WpdIDrKEeoE7EFhNL4n4KxzgxnmRvWZhQUMprYYw9URp0r1hTgXzW97iajiyVWUo= X-Received: by 2002:ac2:5684:: with SMTP id 4mr10666788lfr.386.1627870246615; Sun, 01 Aug 2021 19:10:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:a288:0:0:0:0:0 with HTTP; Sun, 1 Aug 2021 19:10:46 -0700 (PDT) In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> From: Andrew Warkentin Date: Sun, 1 Aug 2021 20:10:46 -0600 Message-ID: To: TUHS main list Content-Type: text/plain; charset="UTF-8" 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8/1/21, Theodore Ts'o wrote: > > 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.) > My OS will be microkernel-based and even the RPC channel to the VFS itself will be a file (with some special semantics). read(), write() and seek() will bypass the VFS entirely and call the kernel to directly communicate with the destination process. The call to create an empty process will return a new RPC channel and there will be an API to temporarily switch to an alternate channel so that VFS calls occur in the child context instead of the parent. All process memory, even the heap and stack, will be implemented as memory-mapped files in a per-process filesystem under /proc/. This will be a special "shadowfs" that allows creating files that shadow ranges of other files (either on disk or in memory). Environment variables will also be exposed in /proc of course. > > 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? > Any process that has permissions to access the RPC channel file and memory mapping shadow files in /proc/ will be able to manipulate the state. The RPC channel will cease to function after the child has been started. setuid and setgid executables will not be supported at all (there will instead be a role-based access control system layered on top of a per-process file permission list, which will allow privilege escalation on exec in certain situations defined by configuration). > > The phrase "all process state will have a file-based interface" sounds > good on paper, but I think it remains to be seen how well a "echo XXX >> /proc//magic-file" API would actually work. The devil is > really in the details.... > Even though everything will use a file-based implementation underneath, there will be a utility library layered on top of it so that user code doesn't have to contain lots of open()-read()/write()-close() boilerplate.