Return-Path: Received: from mail-ig0-f172.google.com ([209.85.213.172]:34432 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932397AbcCKUFh (ORCPT ); Fri, 11 Mar 2016 15:05:37 -0500 MIME-Version: 1.0 In-Reply-To: References: <1456733847-17982-1-git-send-email-agruenba@redhat.com> <20160311140134.GA14808@infradead.org> From: Steve French Date: Fri, 11 Mar 2016 14:05:16 -0600 Message-ID: Subject: Re: [PATCH v18 00/22] Richacls (Core and Ext4) To: Andreas Gruenbacher Cc: Christoph Hellwig , Alexander Viro , "J. Bruce Fields" , Linux NFS Mailing List , "Theodore Ts'o" , "linux-cifs@vger.kernel.org" , Linux API , Trond Myklebust , LKML , XFS Developers , Andreas Dilger , linux-fsdevel , Jeff Layton , linux-ext4 , Anna Schumaker Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Fri, Mar 11, 2016 at 10:11 AM, Andreas Gruenbacher wrote: > On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig w > The model is designed specifically to be compliant with the POSIX > permission model. What assumptions are you talking about? > >> especially by adding allow and deny ACE at the same time. > > I remember from past discussions that a permission model like the > POSIX ACL model that doesn't have DENY ACEs would be more to your > liking. This argument is dead from the start though: NFSv4 ACLs > without DENY ACEs cannot represent basic file permissions like 0604 > where the owning group has fewer permissions than others, for example > (see the richaclex(7) man page). We would end up with a permission > model that isn't even compatible with the traditional POSIX file > permission model, one which nobody else implements or cares about. NFSv4.1 (and later) and Samba's (and cifs.ko and NTFS-3g) ACL model are close enough that doing a common approach that helps all three seems very reasonable. A loosely related question is what can be done for tools around existing interfaces for ACLs. I recently found out NTFS-3g has this xattr: static const char nf_ns_xattr_ntfs_acl[] = "system.ntfs_acl"; which allows you to query system.ntfs_acl xattr to get their full ACL (I hope) from NTFS but it hard to read without tools to parse the blobs better. I was prototyping adding this to cifs.ko for the most current (SMB3 and later) protocol dialects at least to allow backup and debug tools to use this to get the actual ACL. cifs.ko ACL should match almost exactly to NTFS-3g's but I wish I could find some tools that use this xattr so I could try comparing this with cacls.exe output and smbcacls (samba tool) for display detailed ACL information. Any idea of disk management tools for dumping/viewing/editing ntfs ACLs on Linux for comparison? >> It also doesn't help with the issue that the main thing it's trying >> to be compatible with (Windows) actually uses a fundamentally different >> identifier to apply the ACLs to - as long as you're still limited >> to users and groups and not guids we'll still have that mapping problem >> anyway. > > Samba has been dealing with mapping between SIDs and UIDs/GIDs for a > long time, and it's working acceptably well. > > We could store SIDs in ACEs, but that wouldn't make the actual > problems go away: Files on Linux have an owner and an owning group > which are identitifed by UID/GID, whereas a file is owned by a SID > which can be either a user or a group in a SID world. Also, processes > on Linux have an owner and a list of groups which are identified by > UID/GID, so any SIDs stored in filesystems would never match a > process, anyway. Samba's SID<->Username and SID<->UID mapping does work acceptably well, if a bit "over-configurable" ie with many choices for how it is done. (the related RFC2307 mapping needed for mapping usernames to uids across an enterprise, which Samba's winbind can also do is helpful much more broadly - since, unlike a uid which is too small, the username in an NFS ACLs are basically a one to one mapping for Samba to SIDs (there are may samba vfs modules for different OS that already do this, including a one for an earlier version of Linux RichACLs) Sounds like I need to quickly rework the SMB3 ACL helper functions for cifs.ko Also do you know where is the current version of the corresponding vfs_richacl for Samba which works with the current RichACL format? -- Thanks, Steve