Open bol-van opened 11 months ago
Can you elaborate more ? Where did you command chown/chmod ? through smb client ? or on local share directory ? So my questions are:
I did chown/chmod on the systems where ksmbd runs.
SMB client is windows. net use X: \ksmbd-server\share /user:user
ksmbd-server is openwrt. just install samba4-server instead of ksmbd and it works
I also have this issue after switching from samba to ksmbd. Supplementary/extra groups defined in /etc/group using "usermod -a -G group user" are ignored, which results in no access if there are no other/world rights.
So for example using the user/groups from the OP and no other/world rights, there is access to a file/dir when either the user or the group matches the user or primary group: -rw-rw---- user:group -rw-rw---- otheruser:group -rw-rw---- user:othergroup
However there is no access for extra groups, not even read: -rw-rw---- otheruser:sftp
Server and client are running kernel 6.10.11, client is using systemd mount: [Mount] What=//server/share Where=/mnt/mount Type=cifs Options=uid=1000,gid=1000,credentials=/home/user/.smbcred
Which results in the following mount: //server/share on /mnt/mount type cifs (rw,relatime,vers=3.1.1,cache=strict,username=user,domain=domain.com,uid=1000,forceuid,gid=1000,forcegid,addr=ip.add.re.ss,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
EDIT: forgot to mention that setting "force group (S)" on the share can be a sort of workaround, although probably not advised and only usable in single user scenarios. So in the no access example if "force group = sftp" is used, then access is possible.
@namjaejeon,
This looks like the same issue as https://github.com/cifsd-team/ksmbd-tools/issues/200#issuecomment-2352791784.
@atheik Thanks for your check:), I am working it now.
@namjaejeon,
Thank you for the fix! I left some preliminary comments. I will test your patches more later this week.
@atheik I have updated ksmbd patch as you pointed out. https://github.com/namjaejeon/ksmbd/commit/01d9be533081c56a922181a07e87654e6d1c5698 Feel free to check this patch at this week. Thanks for your review!
@atheik Hmm.. I need to add login_response_extension ipc command for backward compatibility. I need more time for this. I will share if it is ready. Thanks!
@atheik Can you check these patches ? https://github.com/namjaejeon/ksmbd/commit/4a6642e1f11a843704b22a4138f5d9e6d09614ed https://github.com/namjaejeon/ksmbd-tools/commit/1f87e4ec4f4b1add301425c16fe6028e7ca03f38
Thanks!
@namjaejeon,
Thanks again. I will do some testing.
By the way, here is an alternative approach:
(Apply on commit 8cd0f00 and commit 78bef66, respectively.)
Edit: I will add here that I don't know if my approach is any good. I did very little testing of these patches.
By the way, here is an alternative approach:
@atheik Okay, Looks clean. Have you checked backward compatibility with the following combinations ?
@namjaejeon,
Have you checked backward compatibility with the following combinations ?
For your approach, I have checked these combinations:
For my approach, I have checked the equivalent combinations.
Neither of our approaches work with Kerberos 5. First, looks like Kerberos 5 authentication has always had intermittent failures, and here is a fix:
Next, both of our approaches hit ksmbd: SPNEGO_AUTHEN_REQUEST failure
due to failed ipc_validate_msg()
in ipc_msg_send_request()
in ksmbd_ipc_spnego_authen_request()
.
Here's new version of my approach that works with Kerberos 5:
Unfortunately, for my approach, the change I made to ipc_validate_msg()
means that new ksmbd-tools would not be compatible with old ksmbd when using Kerberos 5 authentication. (As a side note, looking at commit f27e0ed, I can't say I understand the motivation.)
As a side note, looking at commit https://github.com/namjaejeon/ksmbd/commit/f27e0edb0c8d8cae2b645093026ebac7d3bf9e96, I can't say I understand the motivation
I have forwarded a mail to your gmail. There is vulnerability report regarding to this. and proved memory overrun and slab out of bounds. Let me know if you don't understand motivation after reading a mail. Thanks.
@atheik the patches look good. user struct is allocated with kmalloc in ksmbd_alloc_user. So we need to initialize ->ngroup and ->sgid as zero or NULL. I will directly update it.
Unfortunately, for my approach, the change I made to ipc_validate_msg() means that new ksmbd-tools would not be compatible with old ksmbd when using Kerberos 5 authentication
That was why I have tried to add new login response extension. We need to add login response validation for ->payload of login_response struct in ksmbd module. If it is added, It will make compatibility issue on normal as well as Kerberos 5 authentication.
If it is added, It will make compatibility issue on normal as well as Kerberos 5 authentication.
Please Ignore. it is not true.
@atheik If you are agree, I will mix your patch + login response extension.
@namjaejeon,
You need to gid_t *sgid = NULL
in new_ksmbd_user()
like in my approach. Otherwise, g_free(sgid)
frees uninitialized memory on the first iteration of the do-while loop.
What exactly is the point of mixing our approaches if ksmbd remains limited by KSMBD_MAX_GROUPS
?
Declarations of struct ksmbd_login_response_ext
now differ between ksmbd and ksmbd-tools.
Kerberos 5 support is broken with this approach (Edit: these patches do not work without Kerberos 5 either):
This message was also present with my approach:
Ksmbd 3.4.8 does not allow access to the file system based on supplimentary group In the same scenario if samba4-server used instead of ksmbd - all works as expected.
For example, i am "user" with main group "user" and extra group "sftp" There's dir "dir" and some content inside. "NO ACCESS" means i cant see anything inside "dir" when connected as "user" "OK" means I can see content inside "dir"
chown dir sftp:sftp chmod dir 770 NO ACCESS chown dir sftp:sftp chmod dir 775 OK chown dir sftp:user chmod dir 770 OK