Closed bol-van closed 1 month 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:
@atheik Oops sorry, I have given wrong link to you. I will give you a link again.
@atheik Please review updated patches. and I have applied "[PATCH] ksmbd-tools: fix encode_negTokenTarg() return value" patch to work.ngroup branch.
https://github.com/namjaejeon/ksmbd/commit/5de47963d838822b1972b25fa195dd0d2e72b70b https://github.com/namjaejeon/ksmbd-tools/commit/02b7629257d9d02d5fdc26dcfd23adb5a2c81918
@atheik
Regarding to field-spanning write warning, Please use this patch.
https://github.com/namjaejeon/ksmbd/commit/1bb58abdc4bf86c366949985dea1c960f5aa8d46
@namjaejeon,
The ksmbd 1bb58ab and ksmbd-tools 2dc8237 combination still hits (Edit: Nevermind. I had not fully run the exerciser.)ksmbd: SPNEGO_AUTHEN_REQUEST failure
as per https://github.com/namjaejeon/ksmbd/issues/461#issuecomment-2391960206.
@namjaejeon,
With Kerberos 5, the ksmbd 1bb58ab and ksmbd-tools 78bef66 + "encode_negTokenTarg() fix" combination fails:
[ksmbd.mountd(worker)/31078]: INFO: Authenticated user `atte'
[ksmbd.mountd(worker)/31078]: ERROR: nl_recv() failed, check dmesg, error: Netlink message type is not supported
We need to check resp->login_response.status & KSMBD_USER_FLAG_EXTENSION
in ksmbd_krb5_authenticate()
.
@atheik Right:)
updated your point. and I have also added reserved space for future. https://github.com/namjaejeon/ksmbd/commit/be97dff012b5ba58650b4b82ba69e1d9db29add8 https://github.com/namjaejeon/ksmbd-tools/commit/e2fd5ec17c8f53cfbf5e8de51f7d910a9e70ccba
@atheik
I have updated the patch as you pointed out. https://github.com/namjaejeon/ksmbd/commit/93f3446beca9648cf99db6413bba075c1be74b5e
@namjaejeon,
In what situation is gid_eq(GLOBAL_ROOT_GID, make_kgid(&init_user_ns, user->sgid[i]))
true?
In my testing, I think I only managed to hit the else-branch.
Is it meaningful then that make_kgid(...)
often ends up being called twice per iteration, i.e. is there a reason you do not have a single kgid_t kgid = make_kgid(...)
before the if-else block?
Other than that, the patches look good to me. Thank you for taking the time to fix this!
In what situation is gid_eq(GLOBAL_ROOT_GID, make_kgid(&init_user_ns, user->sgid[i])) true? In my testing, I think I only managed to hit the else-branch.
Ah, Can we set root group to supplementary groups ? I have referenced it with nfsd. I don't know nfsd doesn't allow root group in supplementary groups.
nfsd, auth.c
} else if (flags & NFSEXP_ROOTSQUASH) {
if (uid_eq(new->fsuid, GLOBAL_ROOT_UID))
new->fsuid = exp->ex_anon_uid;
if (gid_eq(new->fsgid, GLOBAL_ROOT_GID))
new->fsgid = exp->ex_anon_gid;
gi = groups_alloc(rqgi->ngroups);
if (!gi)
goto oom;
for (i = 0; i < rqgi->ngroups; i++) {
if (gid_eq(GLOBAL_ROOT_GID, rqgi->gid[i]))
gi->gid[i] = exp->ex_anon_gid;
else
gi->gid[i] = rqgi->gid[i];
}
/* Each thread allocates its own gi, no race */
groups_sort(gi);
} else {
@atheik
Is it meaningful then that make_kgid(...) often ends up being called twice per iteration, i.e. is there a reason you do not have a single kgid_t kgid = make_kgid(...) before the if-else block?
I have updated the patch. Please see. Thanks for review! https://github.com/namjaejeon/ksmbd/commit/cc0af6a609c00072aea436f7939d1c3d30f2e76a
@namjaejeon,
Ah, Can we set root group to supplementary groups ?
I checked Samba's behavior and it has no such restriction:
With this new exerciser, creating directory case4
fails in ksmbd but succeeds in Samba.
The fix would be to remove the gid_eq(GLOBAL_ROOT_GID, ...)
if-branch.
By the way, since we call getgrouplist()
with e->pw_gid
, we will also have the primary group in sgid
.
If sgid
should only contain the supplementary groups, we can do this:
Then, we could set KSMBD_USER_FLAG_EXTENSION
only when login_response_payload_sz(...) > 0
.
@atheik
Done!, Thanks for your check and review!
https://github.com/namjaejeon/ksmbd/commit/7022bc4e6665e6326a9f5e54b385c1c76269ae32 https://github.com/namjaejeon/ksmbd-tools/commit/8139ae529802bc0e4bc4f74dcfb539eb2843885b
@bol-van Can you confirm if your issue is fixed with ksmbd and ksmbd-tools #master branch ?
Yes, it seems to work as expected. Thanks
Thanks for your check:) Closed.
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