[Samba] Unable to support Unix permissions via S-1-5-88 NFS ACEs for Linux clients

Rowland Penny rpenny at samba.org
Thu Oct 24 10:34:48 UTC 2024


On Wed, 23 Oct 2024 06:18:37 +0000
Tom Li via samba <samba at lists.samba.org> wrote:

> Hi all.
> 
> Several years ago, Linux's CIFS kernel driver has implemented two
> little-known options, "idsfromsid" and "modefromsid" for Unix
> permission emulation. When both options are enabled, the Unix file
> user, group, and permissions are stored as SMB ACL entries, and is
> translated from, to, and checked as Unix permissions by the Linux
> client itself, without server involvement. Since SMBv1's Unix
> extension is an obsolete "old, insecure, dialect" [1], while SMBv3's
> new POSIX extension is not finalized yet in Samba [2][3], I believe
> this feature provides a valuable option to achieve Unix compatibility
> if the Linux clients can be trusted (e.g. one user per share).
> 
> To represent unmapped Unix user, group, and mode, three special
> SID ranges are used: S-1-5-88-1-<uid>, S-1-5-88-2-<gid>,
> S-1-5-88-3-<mode>. This is known as the "S-1-5-88 NFS ACEs" since it
> was originally used by Windows for Unix support in NFS [9]. Further,
> Linux also recognizes two additional SID ranges, S-1-22-1-<uid>,
> S-1-22-2-<gid>, which is used by Samba to represent unmapped Unix
> users and groups. For more information, see presentation [4], and
> also Linux source code [5][6][7].
> 
> But it seems that this usage is not supported on Samba.
> 
> The only exceptions are S-1-22-1-<uid> and S-1-22-2-<gid>, which is
> semi- functional on Samba with a "idsfromsid" Linux client - by
> coincidence. In standalone mode, you can create a fileshare that
> points to a directory that is owned by a Unix (server) user without a
> corresponding Samba acount. When this fileshare is mounted on Linux
> with "idsfromsid" enabled, Samba's ACL will report that the files are
> owned by S-1-22-1-<uid>, and S-1-22-2-<gid>, which is understood by
> the Linux driver. If a user and group with the same UID and GID
> exists locally, they're automatically translated to native Unix UIDs
> and GIDs - without using any Unix extension. This can be combined
> with "force user" and "force group" hack, so all newly created files
> will have the same unmapped Unix ownership.
> 
> Otherwise, "idsfromsid" is not working since S-1-5-88-1-<uid>,
> S-1-5-88-2-<gid> are unknown users to Samba and thus ignored (at least
> in standalone mode that I tried, on a FreeBND server w/ ZFS), so one
> can't set or change Unix user or group ownership. "modefromsid"
> is not working as well. Since the SIDs S-1-5-88-3-<mode> are unknown
> users to Samba, Unix permissions are not supported and can't be
> changed on the client.
> 
> Furthermore, I found that these NFS ACLs are in fact are not simply
> unknown, but is actively stripped by Samba. According to [8], in
> nfs4_acls.c, they're silently ignored without being written into the
> NFSv4 ACL of the underlying filesystem.
> 
> 	if (security_descriptor_with_ms_nfs(psd)) {
> 		return NT_STATUS_OK;
> 	}
> 
> Is there any correct or alternative way to use S-1-5-88 NFS ACEs in
> Samba? Did anyone have any success? If there's no way, is Samba's
> development team open to the idea (or patch) to introduce its support
> in the future (controlled by a parameter)?
> 

These are just my thoughts on the subject and I may get shot down in
flames.

I think that while Samba might accept patches to get 'S-1-5-88' to work,
I fear that any NFSv4 ACLs patches will only be accepted after the
Linux kernel accepts them. At present (unless someone knows different),
NFSv4 ACLs only work on freebsd etc and not on Linux.

Rowland



More information about the samba mailing list