samba - Oct 2024 - Unable to support Unix permissions via S-1-5-88 NFS ACEs for Linux clients

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)?

Thanks.

[1] SMB3.1.1 POSIX/Linux Extensions
https://sambaxp.org/fileadmin/user_upload/sambaxp2023-Slides/French_sXP23_SMB3.1.1_POSIX.pdf

[2] How to turn on SMB3 POSIX extensions in Samba server?
https://lists.samba.org/archive/samba/2019-October/226348.html

[3] SMB3-Linux
https://wiki.samba.org/index.php/SMB3-Linux

[4] Linux Access to the Cloud and NAS reborn: Recent progress in SMB3.1.1
(See page 22 and page 51 for idsfromsid and modefromsid)
https://www.snia.org/sites/default/files/SDCEMEA/2020/6%20-%20Steve%20French%20Microsoft%20-%20Linux%20access%20to%20the%20cloud.pdf

[5] fs/smb/client/cifsacl.c
(All supported special SIDs for Unix permissions by Linux driver)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/smb/client/cifsacl.c#n36

[6] smb3: allow uid and gid owners to be set on create with idsfromsid mount
option
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=975221eca5fbfdb4b6b1d17c9e540d4d7627ce18

[7] cifs: allow chmod to set mode bits using special sid
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22442179a5bb8c62c978cdb686cfb3a8f6d110d8

[8] smbd: ignore set NTACL requests which contain S-1-5-88 NFS ACEs 
https://gitlab.com/samba-team/samba/-/merge_requests/1186

[9] Configure Unmapped UNIX User Access
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/hh509017(v=ws.10)

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

On 10/23/24 8:18 AM, Tom Li via samba wrote:
> 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
the plan to achieve POSIX compatibility is by finalizing SMB3 POSIX 
Extensions in Samba and the Linux kernel client. We're mostly there, 
missing bits will implemented and documented in the next 18 months (iirc 
symlinks, POSIX ACL roundtripping, chown semantics, probably more).

You can already get the POSIX mode bits via SMB3 POSIX Extensions. User 
identifiers will be SIDs, so there won't be a way to get the server side 
POSIX ids.

-slow