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

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

[Roland Mainz]

Hi!

----

We've modified the NFSv4 drive for WIndows to support the Nfs3Attr API
uid/gid fields for Cygwin&SFU compatibility, and SID support (local
users mapped to their SIDs, and NFS users/groups without local
accounts are mapped to "S-1-22-1-*" (Unix_User+) and "S-1-22-2-*"
(Unix_Group+)) .

But on Cygwin 3.4.9 and Cygwin 3.5.0 something unexpected happens -
Cygwin /usr/bin/ls shows the wrong uid/uids:
For example the kernel driver fills in uid=197608/gid=197121 (matching
what $ getent passwd/group # says), but ls(1) prints
uid=4278387688/gid=4278387201
It seems Cygwin is mapping ALL NFS3Attr uid/gid values to the
Unix_User+/Unix_Group+ range. On Solaris&Linux the NFS uid/gid values
are correct, and the Windows NFSv4 driver uses the same numeric
values.

Example:
---- snip ----
$ uname -a
CYGWIN_NT-10.0-19045 wingrendel02 3.5.0-0.448.gd56d58ace27b.x86_64
2023-10-30 11:42 UTC x86_64 Cygwin

$ cmd /c 'dir /q'
 Datenträger in Laufwerk T: ist PnfsVolume
 Volumeseriennummer: DEAD-BEEF

 Verzeichnis von T:\test1

31.10.2023  11:53    <DIR>          WINGRENDEL02\roland_mai.
27.10.2023  16:36    <DIR>          ...                    ..
31.10.2023  11:54    <DIR>          WINGRENDEL02\roland_maiksh
30.10.2023  13:05         1.411.059 WINGRENDEL02\roland_maixxx
30.10.2023  12:46    <DIR>          WINGRENDEL02\roland_maijunctiontest1
31.10.2023  05:16    <DIR>          WINGRENDEL02\roland_maibash
               1 Datei(en),      1.415.039 Bytes
               5 Verzeichnis(se),  1.686.773.760 Bytes frei

$ id -a
uid=197608(roland_mainz) gid=197121(Kein)
groups=197121(Kein),545(Benutzer),559(Leistungsprotokollbenutzer),4(INTERAKTIV),66049(KONSOLENANMELDUNG),11(Authentifizierte
Benutzer),15(Diese Organisation),113(Lokales
Konto),4095(CurrentSession),66048(LOKAL),262154(NTLM-Authentifizierung),401408(Mittlere
Verbindlichkeitsstufe)

$ ls -la
total 1386
drwxr-xr-x  5 Unix_User+197608 Unix_Group+197121     120 Oct 31 11:53 .
drwxrwxrwt  3 Unix_User+0      Unix_Group+0           60 Oct 27 17:36 ..
drwxr-xr-x 14 Unix_User+197608 Unix_Group+197121    3660 Oct 31 05:16 bash
drwxr-xr-x  2 Unix_User+197608 Unix_Group+197121      60 Oct 30 12:46
junctiontest1
drwxr-xr-x  3 Unix_User+197608 Unix_Group+197121      80 Oct 31 11:54 ksh
-rwxr-xr-x  1 Unix_User+197608 Unix_Group+197121 1411059 Oct 30 13:05 xxx

$ ls -lan
total 1386
drwxr-xr-x  5 4278387688 4278387201     120 Oct 31 11:53 .
drwxrwxrwt  3 4278190080 4278190080      60 Oct 27 17:36 ..
drwxr-xr-x 14 4278387688 4278387201    3660 Oct 31 05:16 bash
drwxr-xr-x  2 4278387688 4278387201      60 Oct 30 12:46 junctiontest1
drwxr-xr-x  3 4278387688 4278387201      80 Oct 31 11:54 ksh
-rwxr-xr-x  1 4278387688 4278387201 1411059 Oct 30 13:05 xxx
---- snip ----

Is the Cygwin behaviour (i.e. mapping of NFS3Attr uid/gid to different
uid/gid in Cygwin $ ls -n #) intended ?

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

[Roland Mainz]

On Tue, Oct 31, 2023 at 5:20 PM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> We've modified the NFSv4 drive for WIndows to support the Nfs3Attr API
> uid/gid fields for Cygwin&SFU compatibility, and SID support (local
> users mapped to their SIDs, and NFS users/groups without local
> accounts are mapped to "S-1-22-1-*" (Unix_User+) and "S-1-22-2-*"
> (Unix_Group+)) .
>
> But on Cygwin 3.4.9 and Cygwin 3.5.0 something unexpected happens -
> Cygwin /usr/bin/ls shows the wrong uid/uids:
> For example the kernel driver fills in uid=197608/gid=197121 (matching
> what $ getent passwd/group # says), but ls(1) prints
> uid=4278387688/gid=4278387201
> It seems Cygwin is mapping ALL NFS3Attr uid/gid values to the
> Unix_User+/Unix_Group+ range. On Solaris&Linux the NFS uid/gid values
> are correct, and the Windows NFSv4 driver uses the same numeric
> values.
>
> Example:
> ---- snip ----
> $ uname -a
> CYGWIN_NT-10.0-19045 wingrendel02 3.5.0-0.448.gd56d58ace27b.x86_64
> 2023-10-30 11:42 UTC x86_64 Cygwin
>
> $ cmd /c 'dir /q'
>  Datenträger in Laufwerk T: ist PnfsVolume
>  Volumeseriennummer: DEAD-BEEF
>
>  Verzeichnis von T:\test1
>
> 31.10.2023  11:53    <DIR>          WINGRENDEL02\roland_mai.
> 27.10.2023  16:36    <DIR>          ...                    ..
> 31.10.2023  11:54    <DIR>          WINGRENDEL02\roland_maiksh
> 30.10.2023  13:05         1.411.059 WINGRENDEL02\roland_maixxx
> 30.10.2023  12:46    <DIR>          WINGRENDEL02\roland_maijunctiontest1
> 31.10.2023  05:16    <DIR>          WINGRENDEL02\roland_maibash
>                1 Datei(en),      1.415.039 Bytes
>                5 Verzeichnis(se),  1.686.773.760 Bytes frei
>
> $ id -a
> uid=197608(roland_mainz) gid=197121(Kein)
> groups=197121(Kein),545(Benutzer),559(Leistungsprotokollbenutzer),4(INTERAKTIV),66049(KONSOLENANMELDUNG),11(Authentifizierte
> Benutzer),15(Diese Organisation),113(Lokales
> Konto),4095(CurrentSession),66048(LOKAL),262154(NTLM-Authentifizierung),401408(Mittlere
> Verbindlichkeitsstufe)
>
> $ ls -la
> total 1386
> drwxr-xr-x  5 Unix_User+197608 Unix_Group+197121     120 Oct 31 11:53 .
> drwxrwxrwt  3 Unix_User+0      Unix_Group+0           60 Oct 27 17:36 ..
> drwxr-xr-x 14 Unix_User+197608 Unix_Group+197121    3660 Oct 31 05:16 bash
> drwxr-xr-x  2 Unix_User+197608 Unix_Group+197121      60 Oct 30 12:46
> junctiontest1
> drwxr-xr-x  3 Unix_User+197608 Unix_Group+197121      80 Oct 31 11:54 ksh
> -rwxr-xr-x  1 Unix_User+197608 Unix_Group+197121 1411059 Oct 30 13:05 xxx
>
> $ ls -lan
> total 1386
> drwxr-xr-x  5 4278387688 4278387201     120 Oct 31 11:53 .
> drwxrwxrwt  3 4278190080 4278190080      60 Oct 27 17:36 ..
> drwxr-xr-x 14 4278387688 4278387201    3660 Oct 31 05:16 bash
> drwxr-xr-x  2 4278387688 4278387201      60 Oct 30 12:46 junctiontest1
> drwxr-xr-x  3 4278387688 4278387201      80 Oct 31 11:54 ksh
> -rwxr-xr-x  1 4278387688 4278387201 1411059 Oct 30 13:05 xxx
> ---- snip ----
>
> 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 ----

Both have no effect, as the test machine is NOT in a domain, and if I
understand the Cygwin code in |fetch_posix_offset()| correctly a
"trustPosixOffset" value below PRIMARY_POSIX_OFFSET (including 0x0)
will not work.

Corinna: Is there any way to get a "trustPosixOffset" value of 0
working on a standalone (not in a domain) machine (e.g. via registry
settings), so that on an NFS filesystem the NFS uid/gid are mapped
1:1/unchanged to the Cygwin uid/gids ? Yes, I know, it might cause
uid/gid collisions, but right now, for this use case, the risk is
acceptable...

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

[Corinna Vinschen]

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

If this doesn't fit your needs, you have to overload what's given to you
by maintaining this info via /etc/passwd and /etc/group entries.


Corinna

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

[Roland Mainz]

On Mon, Nov 13, 2023 at 8:39 PM 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

OK...
... note that this is our new NFSv4.1 driver for Windows, not the
Microsoft NFSv3 driver which comes with Windows (10) itself.

> If this doesn't fit your needs, you have to overload what's given to you
> by maintaining this info via /etc/passwd and /etc/group entries.

OK, I'll try to do some digging from there...

Another question:
In the original email I send this output:
---- snip ----
$ ls -la
total 1386
drwxr-xr-x  5 Unix_User+197608 Unix_Group+197121     120 Oct 31 11:53 .
drwxrwxrwt  3 Unix_User+0      Unix_Group+0           60 Oct 27 17:36 ..
drwxr-xr-x 14 Unix_User+197608 Unix_Group+197121    3660 Oct 31 05:16 bash
drwxr-xr-x  2 Unix_User+197608 Unix_Group+197121      60 Oct 30 12:46
junctiontest1
drwxr-xr-x  3 Unix_User+197608 Unix_Group+197121      80 Oct 31 11:54 ksh
-rwxr-xr-x  1 Unix_User+197608 Unix_Group+197121 1411059 Oct 30 13:05 xxx

$ ls -lan
total 1386
drwxr-xr-x  5 4278387688 4278387201     120 Oct 31 11:53 .
drwxrwxrwt  3 4278190080 4278190080      60 Oct 27 17:36 ..
drwxr-xr-x 14 4278387688 4278387201    3660 Oct 31 05:16 bash
drwxr-xr-x  2 4278387688 4278387201      60 Oct 30 12:46 junctiontest1
drwxr-xr-x  3 4278387688 4278387201      80 Oct 31 11:54 ksh
-rwxr-xr-x  1 4278387688 4278387201 1411059 Oct 30 13:05 xxx
---- snip ----

username "Unix_User+197608" in this case gets the numeric Cygwin
uid=='4278387688', while the expected uid would be '197608' (what the
NFSv4.1 driver sets in the Nfsv3Attr API).
Little bit playing around inthe Cygwin shell gives me $ bash -c 'echo
$((4278387688 - 0xFF000000))' # which prints the expected "197608" ...
... where in the Cygwin codebase is 0xFF000000 applied to the uid from
the NFSv4.1 driver - and WHY ?

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: 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

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

[Corinna Vinschen]

On Nov 13 21:41, Roland Mainz wrote:
> On Mon, Nov 13, 2023 at 8:39 PM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> >[...]
> > 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
> 
> OK...
> ... note that this is our new NFSv4.1 driver for Windows, not the
> Microsoft NFSv3 driver which comes with Windows (10) itself.

As I wrote a couple of times, we don't support unofficial drivers.
For the time being, you're on your own.

> > If this doesn't fit your needs, you have to overload what's given to you
> > by maintaining this info via /etc/passwd and /etc/group entries.
> 
> OK, I'll try to do some digging from there...
> 
> Another question:
> In the original email I send this output:
> ---- snip ----
> [...]
> ---- snip ----
> 
> username "Unix_User+197608" in this case gets the numeric Cygwin
> uid=='4278387688', while the expected uid would be '197608' (what the
> NFSv4.1 driver sets in the Nfsv3Attr API).
> Little bit playing around inthe Cygwin shell gives me $ bash -c 'echo
> $((4278387688 - 0xFF000000))' # which prints the expected "197608" ...
> ... where in the Cygwin codebase is 0xFF000000 applied to the uid from
> the NFSv4.1 driver - and WHY ?

Check for the fhandler_base::fstat_by_nfs_ea() method and a few snippets
in pwdgrp::fetch_account_from_windows().  The reason is that unix
uids/gids have a high probability to collide with the uids/gids of the
BUILTIN and NT_AUTHORITY domains.  The uids/gid offsets are chosen so
that collisions with existing ids are unlikely.

The important thing to keep in mind is that we don't know if a Unix id
is equivalent to a Windows id.

That's what id mapping is designed for!

Either AD or a RFC2307 name mapping server, see cygpsid::get_id() and
cyg_ldap::fetch_unix_sid_from_ad() as well as
cyg_ldap::fetch_unix_name_from_rfc2307())

-----------------------------------------------------------------------
Given this is the cygwin-developers mailing list, I trust that you are
planning to contribute code to Cygwin itself.  Otherwise this is the
wrong mailing list to discuss this.  If the first, here are a few hints:
-----------------------------------------------------------------------

- I will not allow code into Cygwin which simply overrides the mapping
  in pwdgrp::fetch_account_from_windows(), converting Unix ids 1:1 to
  Cygwin ids and, in turn, Windows SIDs, just because it looks like the
  easy thing to do.  That's just plain wrong.  Some kind of mapping
  outside of Cygwin *will* be required.

Given that, you have three choices:

- (Auto-)create matching /etc/passwd and /etc/group files which map
  the fake "Unix_User/Unix_Group" ids to Windows Usernames and Windows
  SIDs to your liking.  This is the user-side-only option.

- Or you add a poor-man's RFC2307 name service to the client side
  package which adds itself to the registry (see
  cygheap_domain_info::init()) and handles just the minimum of required
  LDAP requests per cyg_ldap::fetch_unix_name_from_rfc2307().  With a
  bit of trickery that would work without touching the Cygwin code base.
  That's the driver-side-only option.

  Bonus points for using another registry key than 
  HKLM/SOFTWARE/Microsoft/ServicesForNFS/Rfc2307Domain and providing
  a Cygwin patch to check for this registry key additionally.

- Or you make sure that the NFS4.1 filesystem does not return NFS as
  its filesystem name.  That may sound surprising at first, but Windows
  itself doesn't care in the least for the filesystem name.  Cygwin OTOH
  cares.

  So, here's how you could do it:

  - In the driver, make sure the filesystem name returned in
    FILE_FS_ATTRIBUTE_INFORMATION is something like "NFS4".  This allows
    to separate the Cygwin behaviour in terms of the MSFT NFSv3 server
    from the behaviour in terms of the NFSv4 server(*).

    In other words, you could add code to fs_info::update() which
    recognizes the NFS4 string and sets another filesystem bit in the
    fs_info class.  Then you create the matching methods in path_conv,
    i. e., fs_is_nfs4() and a combining operator like fs_is_any_nfs().

  - Now Cygwin is free to behave differently.  In particular there's no
    reason left to use the Nfsv3Attr API.  Cygwin can decide to fetch
    Windows standard security information via NtQuerySecurityObject if
    path_conv::is_is_nfs4() is true.

  - As a result, the mapping from Unix ids to Cygwin ids doesn't
    require to call a name service anymore, because the NFS4 client
    can decide what SID to return on its own. These SIDs can be valid
    Windows SIDs known to the local SAM or the responsible AD service,
    i. e., existing Windows user or group SIDs.  As long as followup
    calls to LookupAccountSidW/ LookupAccountNameW return with valid
    information, you're done.

    (*) There's another way to do that, but this is something to discuss
        if you decide to contribute code to Cygwin.

If you decide to do everything in userspace or in the NFSv4 driver,
please ask further questions on the cygwin ML.  If you're willing
to contribute code to Cygwin, we can keep the discussion here.

Either way, it would be helpful if you could choose one person to be the
point of contact, ideally you for example. I'm not willing to be
flattened out by discussions with multiple independent people from the same
group, all demanding the same stuff over and over again.  Thanks.


Corinna

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

[Corinna Vinschen]

On Nov 15 13:57, Corinna Vinschen wrote:
>     In other words, you could add code to fs_info::update() which
>     recognizes the NFS4 string and sets another filesystem bit in the
>     fs_info class.  Then you create the matching methods in path_conv,
>     i. e., fs_is_nfs4() and a combining operator like fs_is_any_nfs().

While at it, the existing operator fs_is_nfs() shoulds be renamed to
fs_is_nfs3().  That makes sure that all occurences of fs_is_nfs() will
have to be scrutinized and changed accordingly.

>   - Now Cygwin is free to behave differently.  In particular there's no
>     reason left to use the Nfsv3Attr API.  Cygwin can decide to fetch
>     Windows standard security information via NtQuerySecurityObject if
>     path_conv::is_is_nfs4() is true.
> 
>   - As a result, the mapping from Unix ids to Cygwin ids doesn't
>     require to call a name service anymore, because the NFS4 client

..., aka NFS4 driver, if that was unclear, ...

>     can decide what SID to return on its own. These SIDs can be valid
>     Windows SIDs known to the local SAM or the responsible AD service,
>     i. e., existing Windows user or group SIDs.  As long as followup
>     calls to LookupAccountSidW/ LookupAccountNameW return with valid
>     information, you're done.

That should go without saying, but it's better talking about apparent
self-evidence than just implying it:

The id mapping should refrain from doing a fully automatic translation
along the lines of:

  UID --> S-1-5-21-<COMPUTER SID>-<UID-as-RID>
  GID --> S-1-5-21-<COMPUTER SID>-<GID-as-RID>

and vice versa.

Not only will that lead to collisions, it would also be dangerous,
especially if you're not using AD, but stand-alone Windows machines.
Assuming this scenario:

  WindowsMachine1
                   <---> NFSServer
  WindowsMachine2

The SIDs on the two machines are different, and the RIDs on both
machines are not necessarily the same for the same physical user,
even if the username is the same.  And even *iff* the RIDs for
an account of the same name is the same on both machines, the iron
rule is: if the SID is different, it's another user.

So whatever you do, you need some kind of mapping instance.


Corinna