[Samba] Samba omitting the user group setting, might be a bug

Fyodor Kravchenko fedd at vsetec.com
Thu Feb 1 15:40:32 UTC 2024


Hello,

I am experiencing a strange behaviour that I think might be a bug. I was 
advised to consult the mailing list instead of trying to file a bug, so 
here it is.

I have a user `kate` which is both a member of a `family` group and a 
`feddkate` group. There is a share called `FeddAndKate` which I what to 
be accessible to the `feddkate` group but not to a `family` group, and 
I've set up the permissions accordingly. Everything works as expected 
when kate, fedd or others log in via ssh, but Samba fails to adhere the 
permissions set.

The most strange thing is that when I log in as `kate` for the first 
time it lets her to see the `ls`:


$ smbclient -U kate \\\\10.75.9.21\\FeddKate
Password for [LITTLEBASKET\kate]:
Try "help" to get a list of possible commands.
smb: \> ls
   .                                   D        0  Tue Jan 30 18:55:09 2024
   ..                                  D        0  Mon Dec 18 16:09:48 2023
   uvedomlenie.pdf                     N   361117  Mon Jan 12 18:25:29 2015
......etc.........


However when I exit and log in again it suddenly restricts her from 
seeing the directory contents:


$ smbclient -U kate \\\\10.75.9.21\\FeddKate
Password for [LITTLEBASKET\kate]:
Try "help" to get a list of possible commands.
smb: \> ls
NT_STATUS_ACCESS_DENIED listing \*


The log file on debug level 6 looks differently for both situations. 
Here the directory list works:


[2024/01/30 23:48:22.301508,  4] 
../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
   setting sec ctx (1000, 1000) - sec_ctx_stack_ndx = 0
[2024/01/30 23:48:22.301520,  5] 
../../libcli/security/security_token.c:56(security_token_debug)
   Security token SIDs (10):
     SID[  0]: S-1-5-21-3975486732-3624466930-94389381-1001
     SID[  1]: S-1-5-21-3975486732-3624466930-94389381-513
     SID[  2]: S-1-5-21-3975486732-3624466930-94389381-1003
     SID[  3]: S-1-22-2-100
     SID[  4]: S-1-1-0
     SID[  5]: S-1-5-2
     SID[  6]: S-1-5-11
     SID[  7]: S-1-22-1-1000
     SID[  8]: S-1-22-2-1000
     SID[  9]: S-1-22-2-1001
    Privileges (0x               0):
    Rights (0x               0):
[2024/01/30 23:48:22.301575,  5] 
../../source3/auth/token_util.c:873(debug_unix_user_token)
   UNIX token of user 1000
   Primary group is 1000 and contains 2 supplementary groups
   Group[  0]: 1001
   Group[  1]: 100
[2024/01/30 23:48:22.301613,  5] 
../../source3/smbd/uid.c:293(print_impersonation_info)
   print_impersonation_info: Impersonated user: uid=(1000,1000), 
gid=(0,1000), cwd=[/]
[2024/01/30 23:48:22.301630,  4] 
../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
   setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2024/01/30 23:48:22.301641,  5] 
../../libcli/security/security_token.c:52(security_token_debug)
   Security token: (NULL)
[2024/01/30 23:48:22.301651,  5] 
../../source3/auth/token_util.c:873(debug_unix_user_token)
   UNIX token of user 0
   Primary group is 0 and contains 0 supplementary groups
[2024/01/30 23:48:22.301676,  5] 
../../source3/smbd/uid.c:493(smbd_change_to_root_user)
   change_to_root_user: now uid=(0,0) gid=(0,0)
[2024/01/30 23:48:22.301710,  2] 
../../source3/smbd/service.c:852(make_connection_snum)
   fdell (ipv4:10.75.6.119:41506) connect to service FeddKate initially 
as user kate (uid=1000, gid=1000) (pid 1183)
[2024/01/30 23:48:22.301726,  5] 
../../lib/dbwrap/dbwrap.c:146(dbwrap_lock_order_lock)
   dbwrap_lock_order_lock: check lock order 1 for 
/run/samba/smbXsrv_tcon_global.tdb
[2024/01/30 23:48:22.301741,  5] 
../../lib/dbwrap/dbwrap.c:178(dbwrap_lock_order_unlock)
   dbwrap_lock_order_unlock: release lock order 1 for 
/run/samba/smbXsrv_tcon_global.tdb
[2024/01/30 23:48:22.301762,  5] 
../../libcli/smb/smb2_signing.c:173(smb2_signing_sign_pdu)
   signed SMB2 message

......etc............


Here it denies permission (disregard the clock, collected it from 
different parts of the log file):

[2024/01/30 23:41:10.198795,  4] 
../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
   setting sec ctx (1000, 1000) - sec_ctx_stack_ndx = 0
[2024/01/30 23:41:10.198830,  5] 
../../libcli/security/security_token.c:56(security_token_debug)
   Security token SIDs (9):
     SID[  0]: S-1-5-21-3975486732-3624466930-94389381-1001
     SID[  1]: S-1-5-21-3975486732-3624466930-94389381-513
     SID[  2]: S-1-5-21-3975486732-3624466930-94389381-1003
     SID[  3]: S-1-22-2-100
     SID[  4]: S-1-1-0
     SID[  5]: S-1-5-2
     SID[  6]: S-1-5-11
     SID[  7]: S-1-22-1-1000
     SID[  8]: S-1-22-2-1000
    Privileges (0x               0):
    Rights (0x               0):
[2024/01/30 23:41:10.198906,  5] 
../../source3/auth/token_util.c:873(debug_unix_user_token)
   UNIX token of user 1000
   Primary group is 1000 and contains 1 supplementary groups
   Group[  0]: 100
[2024/01/30 23:41:10.198946,  4] ../../source3/smbd/vfs.c:939(vfs_ChDir)
   vfs_ChDir to /srv/archive/FeddAndKate
[2024/01/30 23:41:10.198968,  0] 
../../source3/smbd/service.c:166(chdir_current_service)
   chdir_current_service: vfs_ChDir(/srv/archive/FeddAndKate) failed: 
Permission denied. Current token: uid=1000, gid=1000, 1 groups: 100
[2024/01/30 23:41:10.198997,  3] 
../../source3/smbd/smb2_server.c:3861(smbd_smb2_request_error_ex)
   smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] 
status[NT_STATUS_ACCESS_DENIED] || at ../../source3/smbd/smb2_server.c:3147

-----etc---etc......


I've googled somebody with a similar behaviour of Samba omitting an 
arbitrary group, and found a bug report regarding this line of code:

https://github.com/samba-team/samba/blob/9b2f2302ee4828ae54f5903a3bf649ffd255fb4a/source3/auth/auth_util.c#L635 


This is the bug report:

https://bugzilla.samba.org/show_bug.cgi?id=10618


It says resolved-fixed but not for my situation.

Have to add about the environment - this is an unprivileged TurnKey 
Fileserver Linux container run under Proxmox. The extensive googling for 
the problem suggests Samba will not work in such environment because of 
ACL and such, but I need a fileserver as an unprivileged container, 
mapping the same directories the FileServer would serve to other 
containers, and if not for this little bug I'd be quite happy.

Do the user groups come in different order from system to Samba in my 
environment, or cached somewhere between the logins, so we can't 
arbitrarily expect the zeroth ID to be of the type `BOTH`?

Best regards,

fedd




More information about the samba mailing list