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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32097 invoked from network); 22 Jan 2021 00:31:00 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2021 00:31:00 -0000 Received: from mail-yb1-f178.google.com ([209.85.219.178]) by 1ess; Thu Jan 21 19:01:06 -0500 2021 Received: by mail-yb1-f178.google.com with SMTP id i141so3847095yba.0 for <9front@9front.org>; Thu, 21 Jan 2021 16:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=rRmVxbAZS9k2EKgaWRJQ1Dt7w6EE3kL+7OvDW/ySwCw=; b=GDTItwjcivzA/GNZ0B+j0awBPxJZ01szvXOk0JnDna7BkxXHUAzrre2LM+PSBdeE5E VnZveUSYImlRum5qNM7nj13LDRfE+sb5h5NBVUtXpcY1hOVI/97DT5Gd7F6FFFCxv1Ep ffuL3QGKJrd3plD3+7VJW5/MdNFNr9H1tCAS/O7WjTz7YNqJUaLBha+cxBkN1eEpWIzZ IO2/OKI/uzpo3Z/d0ru1Q77DZX6Vwe/S0i5XNjLhkVszyPM1+7O4MRGNlFo1dCxRTiN1 nX229uRYgn+46dT4LM5JtR4tT8cwtJHSuMdQp6GlF4kcveIqXvBxn+nujmCzVYP3vtFk ZGug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=rRmVxbAZS9k2EKgaWRJQ1Dt7w6EE3kL+7OvDW/ySwCw=; b=O4xUvaO7G+9DxApcvb0D8eE4IGZ1Nyz4+01FlTTqTt9D4y5ayifLV5Vgmd7Fy8rzxZ EwIVyVUT7usTrCF2h5UrdDu5VRac9VHAgbjhWaOhb48CbvBl1GwofUKZaFOokfAxolj9 T/5c9ik+rblRlN+HF3ZIAm/qyEVlOV0jjzkogo7+Zi260rfb2EXVnfD8cIQcSAcvaUAl R5k59kXse6DKfLGhs+0oktdQC8xEhImEqIljPVmEUhzWVxBY7Mhw8BHaSf7p6H46p4b4 gTrUHseHQK9Pby3FWJLMQFKWQdxGV1jcG1jTQnRp3Omy7DLwFDIVPkJ7iHSz6hMOHjUK 1X5g== X-Gm-Message-State: AOAM531fpbb66bTPgxaKrjf1MVGOnnoXWmaXVCxQy5g7+cfr6X0gNbgS ukt7BXl5U/yBFeDF6edU+ob7rNQap4doqtGra2hLz51DWgg= X-Google-Smtp-Source: ABdhPJxAboNRBN7NRAVF29soVjkBVlXhVQJu5FZwhYehxTlmC+MDfhqAgBMtIYv6w5ZSolhObRuXdE/9jnDH7SoLBhw= X-Received: by 2002:a25:15c4:: with SMTP id 187mr2693287ybv.505.1611273657704; Thu, 21 Jan 2021 16:00:57 -0800 (PST) MIME-Version: 1.0 References: <154A2B81E5307985989F46BE958ACBAC@eigenstate.org> <84C199F8-15A4-4434-AD56-A35AB5CC6F4A@stanleylieber.com> In-Reply-To: From: Silas McCroskey Date: Thu, 21 Jan 2021 16:00:45 -0800 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: responsive CMS full-stack-based XML blockchain-aware self-signing manager Subject: Re: [9front] user none: cwfs vs hjfs Reply-To: 9front@9front.org Precedence: bulk > regular users honor finer grained file permissions, but cannot be masked = from the special # file system. there is a basic conflict here that has no = solution at all. any regular user must be trusted with proc, binding, unbin= ding, this is why user none exists in the first place. Again, I think RFNOMNT makes this false, at least if it actually works as advertised (I've never had reason to test it). The only justification I can come up with for user none is anonymous read access to the filesystem over the network (when that's enabled). It does seem like I'm missing something, because I don't see why services would've been written to become none in that case. - Silas