All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Björn JACKE" <bj@SerNet.DE>
To: Steve French <smfrench@gmail.com>
Cc: Jeremy Allison <jra@samba.org>,
	ronnie sahlberg <ronniesahlberg@gmail.com>,
	Christoph Hellwig <hch@lst.de>, CIFS <linux-cifs@vger.kernel.org>,
	samba-technical <samba-technical@lists.samba.org>
Subject: Re: Displaying streams as xattrs
Date: Fri, 26 May 2023 18:03:20 +0200	[thread overview]
Message-ID: <20230526160320.GA13176@sernet.de> (raw)
In-Reply-To: <CAH2r5mvGb_e-kjLoKpwF3Eg7f7oOGGKcM7rL95SkU4q=pSE1AQ@mail.gmail.com>

On 2023-05-25 at 18:50 -0500 Steve French via samba-technical sent off:
> Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
> and various other
> tools and also via system xattrs).
> Being able to display "RichACLs" makes sense - and I am fine with
> mapping these (and
> probably would make sense to at least have a readonly mapping of the
> existing richacls on
> a file to "posixacl") and RichACLs are very important.
> 
> Wouldn't it be easier to let them also be queried for cifs.ko via
> "system.getrichacl" (or whatever
> the "getrichacl" tool used in various xfstests uses)?
> 
> I was also wondering how we should display (and how to retrieve via
> SMB3) "claims based ACLs" (presumably these are reasonably common on a
> few server types like Windows)?

let's stop calling them RichACLs becuase that was only the name that Andreas
Grünbacher was giving his implementation of the NFS4 ACLs, which however never
mede it upstream to the kernel. Andreas is no longer interested in working on
those actually because because of a long lack of interest by the Kernel
maintainers back in those days. In any case, NFS4 ACLs are the right name, even
if the SMB people don't like the "NFS" in the name.

We have a summary of the state of NFS4 ACLs here:
https://wiki.samba.org/index.php/NFS4_ACL_overview . I recommend taking a
closer look at this.

If cifs.ko would add a mapping of SMB ACLs to the corresponding system.nfs4_acl
EA, this would be nice already but It will only be a limited help if cifs.ko.

The NFS4 ACL model needs to be supported by the Linux kernel also to be really
helpful. The nfs4-acl-tools are there to manage NFS4 ACLs already. To become
really helpful for Linux NFS4 ACLs need to be managable natively and also be
supported with generic filesystems and tools.

I've seen people who abandon to use Linux as client machines because of the
lack of ACL managability. Have in mind that the so called POSIX ACLs are not a
standardized permission model. The POSIX ACLs never passed the status of a
draft standard and the only standardized ACL permission model are in fact the
NFS4 ACLs. One of the main reason why FreeNAS or TrueNAS these days are based
on FreeBSD is the lack of NFS4 ACLs also.

I really wonder why the responsible people in the Kernel developer community
ignore this important topic since so many years. Would be nice to see them join
this thread ...

Björn

  parent reply	other threads:[~2023-05-26 16:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  2:08 Displaying streams as xattrs Steve French
2023-05-22  4:33 ` ronnie sahlberg
2023-05-22  6:39   ` Steve French
2023-05-22 14:41     ` ronnie sahlberg
2023-05-22 16:21     ` Jeremy Allison
2023-05-23  0:59       ` ronnie sahlberg
2023-05-23  2:23         ` Andrew Walker
2023-05-23 16:25         ` Jeremy Allison
2023-05-23 21:44           ` ronnie sahlberg
2023-05-23 22:34             ` Jeremy Allison
2023-05-25 10:57               ` ronnie sahlberg
2023-05-25 16:15                 ` Jeremy Allison
2023-05-26  2:39                   ` ronnie sahlberg
2023-05-26 16:20                     ` Jeremy Allison
2023-05-25  9:39       ` Björn JACKE
2023-05-25 10:49         ` ronnie sahlberg
2023-05-25 16:22           ` Jeremy Allison
2023-05-25 20:11             ` Steve French
2023-05-25 20:22               ` Jeremy Allison
2023-05-25 22:14                 ` Björn JACKE
2023-05-25 23:50                   ` Steve French
2023-05-26  2:16                     ` ronnie sahlberg
2023-05-26 16:03                     ` Björn JACKE [this message]
     [not found]                       ` <CAH2r5muD89QUcaqWNQy5NUwyji9CinN_5kGcfFSQAbpJP5gn+A@mail.gmail.com>
2023-05-27  1:50                         ` Steve French
2023-05-30  7:26                       ` Michael Weiser
2023-05-22 15:36 ` Andrew Walker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230526160320.GA13176@sernet.de \
    --to=bj@sernet.de \
    --cc=hch@lst.de \
    --cc=jra@samba.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=samba-technical@lists.samba.org \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.