From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out03.mta.xmission.com ([166.70.13.233]:42621 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756347AbcIUPyf (ORCPT ); Wed, 21 Sep 2016 11:54:35 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Miklos Szeredi Cc: Seth Forshee , fuse-devel , linux-fsdevel@vger.kernel.org, Michael j Theall , Jean-Pierre =?utf-8?Q?Andr=C3=A9?= , Nikolaus Rath , Andreas Gruenbacher References: <1472478397-131967-1-git-send-email-seth.forshee@canonical.com> Date: Wed, 21 Sep 2016 10:40:53 -0500 In-Reply-To: (Miklos Szeredi's message of "Wed, 21 Sep 2016 10:30:14 +0200") Message-ID: <877fa5gt16.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [PATCH 0/2] Support for posix ACLs in fuse Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Miklos Szeredi writes: > 3) How will richacl's fit into this? As best as I can read the situation richacl support has not yet been merged into Linux yet. Last I was following the richacl discussion there were some fundamental features of richacls that were incompatible with the expectations of ordinary linux applications. The negative acls if my memory serves. That raised some concern if richacls could ever be safely be merged. As I recall Christoph Hellwig was a primary on raising those concerns, and when I read those arguments they seemed persuasive to me. That said richacls (if they happen) will communicate to the filesystem primarily with extended attributes just like the acls, and flag will need to be added to the protocol to enable richacl support in the kernel if and when that exists. Or in short richacls are the same tune but different dance partners. Eric