Project

General

Profile

Bug #13026

Updated by Matt Barden almost 2 years ago

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.

Back