Created attachment 11131 [details] Level 10 debug log (4.2.2) After updating from 4.1.17 to 4.2.2, the following share stop working: [testX] path = /testX browsable = yes force create mode = 0660 force directory mode = 2770 force user = firebird force group = firebird guest ok = no valid users = "+MUC\medical office" invalid users = The user and group "firebird" both exist local on this server: # getent passwd firebird firebird:x:84:84:Firebird Database Owner:/opt/firebird:/bin/false # getent group firebird firebird:x:84: Also the account im using to access (muehlfeld), is member of the domain group "medical office". This are the permissions on the folder: # ls -ld /testX/ drwxr-s--- 2 firebird firebird 6 8. Jun 16:36 /testX/ When I try to access this share, I get "permission denied". When I remove either the "force group" or the "force user" line, then it's possible to access the share. The share like shown above worked great since years with 3.6, 4.0, 4.1. Find attached a level 10 debug log from the try to access this share. I this problem might be the same like in Bug #11082, but Jeremy said there, that it looks like a different problem.
Created attachment 11132 [details] Level 10 debug log (4.1.17) (In reply to Jeremy Allison) > The code in source3/smbd/service.c:343(find_forced_group) is identical in 4.1.x > to 4.2.x and master, so I think you would hit the same problem on 4.1.x. You're right. The code block in service.c is identical in 4.2.2 and 4.1.17. However in 4.1.17 it works. Debug log of the same (accessing the testX share) from 4.1.17 is attached.
It might be related to commit cd4442c7? I can reproduce the problem, and after setting "winbind use default domain" to "No" I can access the share again.
Created attachment 11281 [details] Proposed fix This bug also makes "valid users" not work for cases where there is a user with the same name as a group. user_ok_token() already does the right thing by adding the LOOKUP_NAME_GROUP flag; but lookup_name() was not respecting that flag, and went ahead and looked for users anyway. Please try the attached patch. It fixes my "valid users" issue.
Comment on attachment 11281 [details] Proposed fix Oh that's *absolutely* correct. WELL DONE - *great* catch !
Ok, now I need to see if I can reproduce this with a torture test case so we can ensure we don't regress again !
(In reply to Marc Muehlfeld from comment #0) OK Marc, I've tried to reproduce your problem using current master and with 4.2.x, setting up a share in the same way with the same restrictions, and I do *NOT* see the problem you see. My smb.conf: [global] workgroup = WORKGROUP log file = /usr/local/samba/var/log.%m store dos attributes = yes map hidden = no map system = no map readonly = no kernel oplocks = no kernel change notify = no smb2 leases = yes create mask = 0777 directory mask = 0777 [tmp] path = /tmp/puppettest read only = no force user = puppet force group = puppet guest ok = no valid users = +eng invalid users = ls -ld /tmp/puppettest/ drwx------ 2 puppet puppet 4096 Jul 24 14:02 /tmp/puppettest/ I'm logging on a local jeremy user that is also a member of UNIX group eng. smbclient access this just fine.
Comment on attachment 11131 [details] Level 10 debug log (4.2.2) I don't see any ACCESS_DENIEDs in this log.
(In reply to Justin Maggard from comment #3) Justin, can you post a sample smb.conf so I can get a reproducible test case to add a regression test ?
From phone call - with my smb.conf, create an 'eng' SMB user and I should be able to reproduce the problem.
I just verified that it doesn't actually need to a SMB user -- just a UNIX user named "eng" is good enough.
(In reply to Justin Maggard from comment #10) Still can't reproduce :-(. Given my smb.conf, and a UNIX eng user I can still access the share as 'puppet'. Justin, can you post your entire smb.conf and setup ?
*** Bug 11082 has been marked as a duplicate of this bug. ***
Phew. Finally managed to reproduce with my smb.conf if I set: valid users = +WORKGROUP\eng Should be enough for me to knock up a test case...
Yay. And Justin's patch fixes it of course :-).
I can confirm that the patch works here, too (tested against 4.2.3). Do we need another reviewed-by or can we push it to autobuild?
I'm happy to push with your rb+, but I'd really like a regression test too. I'm working on that right now but it's a really hard thing to test :-).
Created attachment 11291 [details] git-am fix for master. (Finally) here is the regression test that ensures we won't mess this one up again :-). Marc, please review for master ! Thanks, Jeremy.
Comment on attachment 11291 [details] git-am fix for master. LGTM
As the fix is in master, please backport it to 4.{1,2,3}.next as required. Thanks!
Created attachment 11296 [details] git-am cherry-pick from master for 4.3.0, 4.2.next, 4.1.next. Backport for 4.2.next, 4.1.next. I was also going to backport the regression test, but this requires additional test changes to be backported that from master that we probably don't need as it's being continually tested in master now. Please cherry-pick for 4.2.next, 4.1.next.
(In reply to Jeremy Allison from comment #20) What's with 4.3.next? And also ask someone for a review flag on the attachment, you know how this is supposed to work... Thanks!
Hi bug https://bugzilla.samba.org/show_bug.cgi?id=11082 (force user problem with local/nss Users) was marked as a duplicate of this bug, but unfortunately the patch did not solve the force user problem. I have attached debug10 logs to https://bugzilla.samba.org/show_bug.cgi?id=11082 of samba 4.2.3 with that patch applied Regards Hansjörg
(In reply to Stefan (metze) Metzmacher from comment #21) Metze, is there a separate branch for v4-3-test now ? I asked as I'm not aware of that yet.
Comment on attachment 11296 [details] git-am cherry-pick from master for 4.3.0, 4.2.next, 4.1.next. FYI. For direct cherry-picks from master which already have 2 Team reviews and no back-porting changes, in the past I've not always gotten an additional review before sending to Karolin as it hasn't seemed necessary. If you want this step though I'm happy to do that.
Comment on attachment 11296 [details] git-am cherry-pick from master for 4.3.0, 4.2.next, 4.1.next. Edited "Destription" to note this also applies cleanly to v4-3-test (AKA 4.3.0).
(In reply to Jeremy Allison from comment #23) Yes, as 4.3.0rc1 is out of the door. This will be part of 4.3.0rc2... See https://wiki.samba.org/index.php/Release_Planning_for_Samba_4.3
(In reply to Jeremy Allison from comment #24) Having a review for master doesn't mean that the reviewer wants the change to be ported to release branches. It's better to have just one way of doing things...
Pushed to autobuild-v4-[1,2,3]-test
(In reply to Stefan Metzmacher from comment #28) Pushed to v4-[1,2,3]-test