samba sgid not inherited

English Network/Internet
1

HI,
I have a wierd permission problem with with samba.

this is the configuration:


[global]
        workgroup = GRUPPO
        passdb backend = tdbsam
        domain logons = no
        domain master = no
        security = user
        wins support = No
        wins server = xxxx.xxx
        interfaces = eth0
        bind interfaces only = yes
        netbios aliases = testsmb


[testshare]
path = /data/testshare
valid users = @smbRW,@smbRO,@smbTT
write list = @smbRW,@smbTT
read list = @smbRO
create mask = 770
directory mask = 2770
force create mode = 770
force directory mode= 2770

Those are acl and permission for testshare folder on the filesystem (ext4)


testshare permission (please note the sguid)

drwxrws---+ 17 mmm smbRW

testshare acl

# file: .
# owner: mmm
# group: smbRW
# flags: -s-
user::rwx
group::rwx
group:smbRW:rwx
group:smbRO:r-x
group:smbTT:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:smbRW:rwx
default:group:smbRO:r-x
default:group:smbTT:rwx
default:mask::rwx
default:other::---

I used two test accounts:

  • test is member of users and smbRW groups
  • test2 is member of users and smbTT groups

My goal is to permit users belonging to smbRW or smbTT groups to create file and folder inside testshare and those file and folder (and subfolder) should have smbRW group and should inherit al the ACL. I also want this to work the same way
for both local (ie from a terminal) and remote (through samba) access

Local access work as expected:


test@linux-c55h:/data/testshare> mkdir local.test.dir
test@linux-c55h:/data/testshare> ls -la
drwxrws---+  2 test  smbRW 4096 May  3 13:27 local.test.dir

test2@linux-c55h:/data/testshare> mkdir local.test2.dir
drwxrws---+  2 test2 smbRW 4096 May  3 13:30 local.test2.dir

remote access through samba instead:


smbclient -U test //XXXXXX/testshare
Enter GRUPPO	est's password: 
Domain=[LINUX-C55H] OS=[Windows 6.1] Server=[Samba 4.6.16-git.154.2998451b91227.1-SUSE-SLE_12-x86_64]
smb: \> mkdir test.remote.dir
smb: \> exit
# smbclient -U test2 //XXXXXXXXXX/testshare
Enter GRUPPO	est2's password: 
Domain=[LINUX-C55H] OS=[Windows 6.1] Server=[Samba 4.6.16-git.154.2998451b91227.1-SUSE-SLE_12-x86_64]
smb: \> mkdir test2.remote.dir
smb: \> exit

...on the server:

drwxrws---+  2 test  smbRW 4096 May  3 13:32 test.remote.dir
drwxrwx---+  2 test2 smbRW 4096 May  3 13:32 test2.remote.dir    <<<<<<<<<<<NOTE THE MISSING SGID

getfacl test.remote.dir/
# file: test.remote.dir/
# owner: test
# group: smbRW
# flags: -s-
user::rwx
group::rwx
group:smbRW:rwx
group:smbRO:r-x
group:smbTT:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:smbRW:rwx
default:group:smbRO:r-x
default:group:smbTT:rwx
default:mask::rwx
default:other::---

getfacl test2.remote.dir/
# file: test2.remote.dir/
# owner: test2
# group: smbRW
user::rwx
group::rwx
group:smbRW:rwx
group:smbRO:r-x
group:smbTT:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:smbRW:rwx
default:group:smbRO:r-x
default:group:smbTT:rwx
default:mask::rwx
default:other::---

As you can see with the user test which belongs to smbRW, the owner group of the parent folder, everything is as expected, while with the user test2 which belongs to smbTT, a group allowed through acl, the sgid attribute is lost.

I cannot understand why this is happening. Any help would be greatly appreciated
Thank you all.

2

Try to strace smbd process in both cases to see if it does something differently.

3

Hi, i did the test you suggested. strace log are very verbose, but i suppose those are the interesting parts:

this is with the user “test” who belongs to the smbRW group, the directory created correctly inherit the sgid bit


3273  mkdir("test.dir.3", 02770)        = 0
3273  getxattr("test.dir.3", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\7\0\377\377\377\377\10\0\7\0\350\3\0\0\10\0\5\0\351\3\0\0\10\0\7\0\352\3\0\0\20\0\7\0\377\377\377\377 \0\0\0\377\377\377\377", 132) = 60
3273  stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2683, ...}) = 0
3273  getgid()                          = 0
3273  getuid()                          = 1001
3273  getegid()                         = 100
3273  geteuid()                         = 1001
3273  geteuid()                         = 1001
3273  write(9, "2019/05/05 20:03:20.109268, 10,"..., 144) = 144
3273  geteuid()                         = 1001
3273  write(9, "  Calling acl_set_file: test.dir"..., 38) = 38
3273  setxattr("test.dir.3", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\7\0\377\377\377\377\10\0\7\0\350\3\0\0\10\0\5\0\351\3\0\0\10\0\7\0\352\3\0\0\20\0\7\0\377\377\377\377 \0\0\0\377\377\377\377", 60, 0) = 0
3273  lstat("test.dir.3", {st_mode=S_IFDIR|S_ISGID|0770, st_size=4096, ...}) = 0
3273  stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2683, ...}) = 0
3273  getgid()                          = 0

this is with the user “test2” who belongs to the smbTT group, the directory created does not have the sgid bit


3277  mkdir("test2.dir.3", 02770)       = 0
3277  getxattr("test2.dir.3", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\7\0\377\377\377\377\10\0\7\0\350\3\0\0\10\0\5\0\351\3\0\0\10\0\7\0\352\3\0\0\20\0\7\0\377\377\377\377 \0\0\0\377\377\377\377", 132) = 60
3277  stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2683, ...}) = 0
3277  getgid()                          = 0
3277  getuid()                          = 1003
3277  getegid()                         = 100
3277  geteuid()                         = 1003
3277  geteuid()                         = 1003
3277  write(9, "2019/05/05 20:03:47.617941, 10,"..., 144) = 144
3277  geteuid()                         = 1003
3277  write(9, "  Calling acl_set_file: test2.di"..., 39) = 39
3277  setxattr("test2.dir.3", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\7\0\377\377\377\377\10\0\7\0\350\3\0\0\10\0\5\0\351\3\0\0\10\0\7\0\352\3\0\0\20\0\7\0\377\377\377\377 \0\0\0\377\377\377\377", 60, 0) = 0
3277  lstat("test2.dir.3", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
3277  getxattr("test2.dir.3", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\7\0\377\377\377\377\10\0\7\0\350\3\0\0\10\0\5\0\351\3\0\0\10\0\7\0\352\3\0\0\20\0\7\0\377\377\377\377 \0\0\0\377\377\377\377", 132) = 60
3277  stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2683, ...}) = 0
3277  getgid()                          = 0
3277  getuid()                          = 1003
3277  getegid()                         = 100
3277  geteuid()                         = 1003
3277  geteuid()                         = 1003
3277  write(9, "2019/05/05 20:03:47.618609, 10,"..., 144) = 144
3277  geteuid()                         = 1003
3277  write(9, "  Calling acl_set_file: test2.di"..., 39) = 39
3277  setxattr("test2.dir.3", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\7\0\377\377\377\377\10\0\7\0\350\3\0\0\10\0\5\0\351\3\0\0\10\0\7\0\352\3\0\0\20\0\7\0\377\377\377\377 \0\0\0\377\377\377\377", 60, 0) = 0
3277  lstat("test2.dir.3", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0

Any helps would be greatly appreciated!

Thanks in advance

4

Well, SAMBA not only creates directory (using correct mode) but also sets directory ACL. This resets SGID bit. It does not appear to be properly documented (at least in setfacl manual page), but from kernel source:

 * As with chmod, clear the setgit bit if the caller is not in the owning group
 * or capable of CAP_FSETID (see inode_change_ok).

I do not know whether it is possible to tell SAMBA to not touch POSIX ACL. Alternatively do you really need SGID bit on directory? I mean, permissions are already fully defined by default ACLs, what exactly group ownership adds to that?

5

As far as I can tell - no. If SAMBA was compiled with POSIX ACL support it will unconditionally attempt to set them.

OTOH SAMBA has workaround for similar problem with file owner - it will temporary switch to root when setting ACL and permission bits if the file owner and current process UID do not match.

I suggest you raise this issue on SAMBA list. SAMBA documentation suggests that SGID on directories are valid and working scheme; looks like SAMBA needs to implement the same workaround for file group as for file owner.

6

Thank you very much, this explains the behavior

Yes permission are fully defined by def. ACL so I have not any access problem. However I would like to have exactly the same permission inheritance behavior with both remote access through samba and local access.

Thank you for your suggestion, I will raise the issue on the samba mailing list and I will let you know!