On Fri, Mar 11, 2016 at 10:11 AM, Andreas Gruenbacher
<agruenba@xxxxxxxxxx> wrote:
> On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
