Problem related to ID_TYPE_BOTH -Need suggestion

[Abhidnya S Joshi]

Hi Stefan,

With this change, where user is getting set as group, file access through 
Samba works fine. But If we want to export same share with NFS then it 
gives access denied for user testuser1 (This I tried on GPFS). This is 
because while evaluating access, GPFS gets no ACE with user testuser1 and 
its neither part of group testuser1 (as it was set by Samba). Also when I 
try to access file locally on GPFS as testuser1, it gets access denied. 
The ACLs on file in GPFS look like

group:VIRTUAL1\administrator:rwxc:allow
 (X)READ/LIST (X)WRITE/CREATE (-)MKDIR (X)SYNCHRONIZE (X)READ_ACL 
(X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL 
(X)WRITE_ATTR (X)WRITE_NAMED

group:VIRTUAL1\testuser1:rwxc:allow
 (X)READ/LIST (X)WRITE/CREATE (-)MKDIR (X)SYNCHRONIZE (X)READ_ACL 
(X)READ_ATTR  (X)READ_NAMED
 (X)DELETE    (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL 
(X)WRITE_ATTR (X)WRITE_NAMED

Thus I think ID_TYPE_BOTH support + sid_to_gid() call first will cause 
problem with multi protocol environment.

Thanks and Regards
Abhidnya




From:   "Stefan (metze) Metzmacher" <metze at samba.org>
To:     Abhidnya S Joshi/India/IBM at IBMIN, 
Cc:     samba-technical at samba.org
Date:   07/15/2013 06:45 PM
Subject:        Re: Problem related to ID_TYPE_BOTH  -Need suggestion



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

[attachment "signature.asc" deleted by Abhidnya S Joshi/India/IBM]