From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 863DFC433DF for ; Thu, 13 Aug 2020 09:01:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4019F2074D for ; Thu, 13 Aug 2020 09:01:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=crudebyte.com header.i=@crudebyte.com header.b="XLEZSsXO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726102AbgHMJBl (ORCPT ); Thu, 13 Aug 2020 05:01:41 -0400 Received: from lizzy.crudebyte.com ([91.194.90.13]:49545 "EHLO lizzy.crudebyte.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726131AbgHMJBl (ORCPT ); Thu, 13 Aug 2020 05:01:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=lizzy; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Content-ID:Content-Description; bh=xoEU/e+t3YPzZhroZXeZdFynEC84Ts4q65Sao1+LTas=; b=XLEZSsXO4be6wRTPpunR4waBQx qkkew2+Flofmq8uLdJ1kYjYg65q1Fiw2fXiHE4oqI1oDX3QDxLKOSft6+zhxlxbG+zpMRKM2xcUwR BT5BZBf1Mim9lAh8ZFtT4STmw6afx461okxIPhGRNk9neWL9nzBAXFi7kbbScDUKnmtG7+ivvQfJJ JFigffrLRBKBZHdg97dsIjAilcJiu1JMVAM4q8MemWoHjnlwXEfExRsYMovcfZRleMhHCTOzjyc9Q /wZJOQnKqDWb4AaRppdNLCBirIMpwBzpo03SsVZpPG8IotFXhPTh+foEFXhov8BSdEQA4nPPFrSG2 ah1vlBvw==; From: Christian Schoenebeck To: "Dr. David Alan Gilbert" Cc: Greg Kurz , linux-fsdevel@vger.kernel.org, stefanha@redhat.com, mszeredi@redhat.com, vgoyal@redhat.com, gscrivan@redhat.com, dwalsh@redhat.com, chirantan@chromium.org Subject: Re: xattr names for unprivileged stacking? Date: Thu, 13 Aug 2020 11:01:36 +0200 Message-ID: <27541158.PQPtYaGs59@silver> In-Reply-To: <20200812143323.GF2810@work-vm> References: <20200728105503.GE2699@work-vm> <12480108.dgM6XvcGr8@silver> <20200812143323.GF2810@work-vm> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mittwoch, 12. August 2020 16:33:23 CEST Dr. David Alan Gilbert wrote: > > On macOS there was (or actually still is) even a quite complex API which > > separated forks into "resource forks" and "data forks", where resource > > forks were typically used as components of an application binary (e.g. > > menu structure, icons, executable binary modules, text and translations). > > So resource forks not only had names, they also had predefined 16-bit > > type identifiers: > > https://en.wikipedia.org/wiki/Resource_fork > > Yeh, lots of different ways. > > In a way, if you had a way to drop the 64kiB limit on xattr, then you > could have one type of object, but then add new ways of accessing them > as forks. That's yet another question: should xattrs and forks share the same data- and namespace, or rather be orthogonal to each other. Say forks would (one day) have their own ownership and permissions, then restricted environments would want to project forks' permissions onto xattrs, which would suggest an orthogonal approach (i.e. forks having their own xattrs). OTOH a shared namespace would allow a mellow transition for heterogenous systems and their apps from in-memory-only xattrs towards I/O based forks. Another option: shared namespace, but allowing forks having subforks. That would e.g. allow restricted environments to project permissions onto subforks, and the latter in turn being accessible by xattr API at the same time. Or yet another option: shared data space, but nesting the namespace of one side under prefix on the other side (e.g. fork "foo" <=> xattr "fork.foo"). Best regards, Christian Schoenebeck