Problem related to ID_TYPE_BOTH -Need suggestion

[Stefan (metze) Metzmacher]

Hi Abhidnya,

> I've encountered an architectural problem related to id mapping and acls 
> and I would like to collect some ideas how to solve it.
> 
> Problem Description: 
> Windows client connects to Samba4. Win client tries to add ACLs on file 
> for some AD user. The ACL put is successful but the user gets set as 
> group. 
> I tried this with acl_xattr on ext4 and also with nfs4_acl + gpfs on gpfs. 
> On both user gets set as group. idmap backend used is autorid which 
> supports ID_TYPE_BOTH
> 
> Analysis: 
> Samba logs with acl_xattr and ext4:
> 
>  print_canon_ace_list: file ace - return
>   canon_ace index 0. Type = allow SID = 
> S-1-5-21-4161253050-953922356-4292765330-513 gid 13000513 (VIRTUAL1\domain 
> users) SMB_ACL_GROUP ace_flags = 0x0 perms r-x
>   canon_ace index 1. Type = allow SID = 
> S-1-5-21-4161253050-953922356-4292765330-1110 gid 13001110 
> (VIRTUAL1\testuser1) SMB_ACL_GROUP ace_flags = 0x0 perms rwx
>   canon_ace index 2. Type = allow SID = 
> S-1-5-21-4161253050-953922356-4292765330-500 uid 13000500 
> (VIRTUAL1\administrator) SMB_ACL_USER_OBJ ace_flags = 0x10 perms rwx
>   canon_ace index 3. Type = allow SID = 
> S-1-5-21-4161253050-953922356-4292765330-500 gid 13000500 
> (VIRTUAL1\administrator) SMB_ACL_GROUP ace_flags = 0x10 perms rwx
>   canon_ace index 4. Type = allow SID = 
> S-1-5-21-4161253050-953922356-4292765330-513 gid 13000513 (VIRTUAL1\domain 
> users) SMB_ACL_GROUP_OBJ ace_flags = 0x10 perms r-x
>   canon_ace index 5. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER 
> ace_flags = 0x10 perms r-x
> [2013/07/10 08:08:44.092872, 10, pid=1896592, effective(13000500, 
> 13000513), real(13000500, 0), class=acls] 
> smbd/posix_acls.c:847(print_canon_ace_list)
> 
> Here testuser1 is user and set as group.
> For GPFS, Samba log file shows success for sid_to_gid call before setting 
> ACL via gpfs_putacl call. This sid_to_gid is called while filling up ACL 
> structure via smbacl4_fill_ace4 (nfs4_acls.c). Here note that idmap 
> backend used is autorid. Autorid supports ID_TYPE_BOTH. Thus sid_to_gid 
> call succeeds and smbacl4_fill_ace4 sets gid. Thus GPFS understands this 
> user as group. If autorid stops support for ID_TYPE_BOTH, things work fine 
> where user gets recognized as user only. The problem here at least in case 
> of nfs4_acls is the combination of sid_to_gid call first and support for 
> ID_TYPE_BOTH by idmap backend. Any views on this?

This explains how it should work.
I don't see what your real problem is?

Note: with IDMAP_TYPE_BOTH smbd passes the gid values for the users
to the kernel as 'gid'.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130715/44975405/attachment.pgp>