illumos gate

SMB and NFS use crget() as a base for their credentials.
This copies the global kcred, and so sets cr->cr_zone to the global zone.

ZFS uses cr->cr_zone as an argument to kidmap_* calls. kidmap uses this to determine which zone's IDMAP to contact. This means that ZFS always contacts the global zone when doing operations on behalf of an SMB/NFS user, even for non-global-zone servers.

Additionally, SMB specifies global_zone in its explicit calls to idmap; this is leftover from when SMB was not zone-aware, but kIDMAP was.

This causes problems in two ways:
1. If the GZ and NGZ specify different IDMAP name mappings, then the wrong mappings will be used.
2. If the server looks up a sid from one zone, and tries to map the ephemeral id it gets back to a sid in a different zone, then if the ephemeral mapping isn't identical in both zones, problems occur; If it exists in both, it may not map back to the same SID, and if it does not exist in the id-to-sid zone, then ZFS will replace the id with NOBODY, and SMB/NFS will return errors.

Steps to Reproduce:
For the 'explicit call' part:

1. create a user in the global zone: useradd -u 11111 globaluser
2. create a mapping rule in the global zone: idmap add winuser:Administrator@blue.ma.nexenta.com globaluser
3. create a user in the non-global zone: useradd -u 55555 zoneuser
4. create a mapping rule in the non-global zone: idmap add winuser:Administrator@blue.ma.nexenta.com zoneuser
5. Over SMB, on a share exported from the non-global zone, set the owner of a file to the winuser (here, Administrator@blue.ma.nexenta.com)
6. In NGZ: ls -l file.txt

For the SMB incorrect zone cred part:

1. In the NGZ: chmod A+usersid:Administrator@domain:full_set:fd:allow /ngzshare/testdir
(ensure that Administrator@domain doesn't have a uid mapping)
2. In the GZ, idmap flush -a
3. Connect to the SMB share in the NGZ
4. create newfile.txt in testdir over SMB
5. In the NGZ: ls -V testdir/newfile.txt

For the NFS incorrect zone cred part:

1. In the NGZ: chown -s Administrator@domain /ngzshare/ownerfile.txt
2. In the NGZ: idmap flush -a
3. From an NFSv4 client connected to the NGZ share: ls -l ownerfile.txt

alternatively:

1. In the NGZ: chown -s Administrator@domain /ngzshare/ownerfile.txt
2. create a user in the tenant: useradd -u 55555 local_user
3. create a name mapping in the tenant: idmap add winname:Administrator@<domain> unixuser:local_user
4. create a user in the global zone: useradd -u 11111 global_user
5. create a name mapping in the global zone: idmap add winname:Administrator@<domain> unixuser:global_user
6. Connect an NFSv4 client to the share
7. From the NFSv4 client, ls -l ownerfile.txt

Expected Results:
For 1): The owner of the file is zoneuser (uid 55555)

For 2): the file has a 'usersid:Administrator@domain' inherited SID

For 3): the owner is listed successfully

For 4): the owner is zoneuser (uid 55555)

Actual Results:
For 1): The owner of the file is globaluser (uid 11111)

For 2): the file has a 'nobody' inherited SID

For 3): operation fails with EPERM/NFS4ERR_PERM

For 4): the owner is globaluser (uid 11111)

Testing was done by following all of the above reproduction steps, and verifying the results specified in 'expected results' occur.