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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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