Cygwin 3.5 mapping uid/gid on NFSv4 filesystem to unexpected IDs ...

[Cedric Blancher]

On Mon, 13 Nov 2023 at 20:39, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
>
> On Nov 10 13:22, Roland Mainz wrote:
> > On Tue, Oct 31, 2023 at 5:20 PM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> > >
> > > Is the Cygwin behaviour (i.e. mapping of NFS3Attr uid/gid to different
> > > uid/gid in Cygwin $ ls -n #) intended ?
> >
> > In the meantime I tried this:
> > ---- snip ----
> > # Map NFSv4 uid/gid 1:1 to Cygwin uid/gid - does not work
> > regtool -i set '/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/NTDS/trustPosixOffset'
> > 0x0
> > regtool -i set '/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Netlogon/Parameters/trustPosixOffset'
> > 0x0
> > ---- snip ----
>
> This can't work.  trustPosixOffset is not a value in the registry. It's
> stored in AD only and fetched from the domain's system container via
> LDAP.
>
> uid/gid mapping between NFS server and Cygwin works by utilizing the NFS
> client's identity mapping as described in
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs

CC Benjamin Coddington <bcodding@redhat.com>, as he is Redhat like
Corinna, and knows about NFSv4

OK, full stop. I think there is the problem:
1. The NFSv4 protocol no longer uses uids and gids, it uses strings
for owner and owner_group, which are translated on the NFSv4 client
side to local uid and gid numbers via a builtin idmapper service.
2. This is no longer NFSv3, and not the Microsoft NFSv3 driver, which
provides NO SID for user and group.
3. The Windows NFSv4 driver is more like SAMBA, plus adds the Nfs3Attr
extension.

Details:
What the NFSv4 Windows driver does is take the NFSv4 owner and
owner_group strings, maps (builtin idmapper) them to *local* uid/gid
values and returns them in the Nfs3Attr extension.

The idmapper in the driver has three modes right now to fo that:
"Mode 1": LDAP, which takes local uid and gid numbers from LDAP, and
it is assumed that the account name matches a local Windows account
(like
"Mode 2": Cygwin mode, where the passwd and group information from
Cygwin is used: NFSv4 owner/owner_group strings are input into Cygwin
API, output is uid/gid *and* SID for user/group. If no Cygwin account
is found Unix_User/Unix_Group yre returned for SID. Intentionally no
LDAP is used!!
"Mode 3": Static mapping, like "Mode 2", but just a static table from
NFSv4 owner and owner_group to local account names and local uid/gid.

I think Roland is talking about "Mode 2", which is the default if
Cygwin is installed.
But in that case Cygwin's newlib still do a MAP_UNIX_TO_CYGWIN_ID(uid)
and MAP_UNIX_TO_CYGWIN_ID(gid), i.e. add UNIX_POSIX_OFFSET
(0xff000000), which RUINS the concept of NFSv4's idmapper by trashing
valid local uid/gid values with 0xff000000.

My proposal would be to stop doing a MAP_UNIX_TO_CYGWIN_ID(uid) and
MAP_UNIX_TO_CYGWIN_ID(gid) and just use uid and gid as returned by the
driver - *if* the filesystem returns valid SID data. That should work
for SAMBA and the Windows NFSv4 driver, and doesn't require extra
checks specifically for the NFSv4 Windows driver.

Or just treat the NFSv4 driver just like SAMBA.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur