Eugene Pankov
2019-Feb-19 17:13 UTC
[Samba] Reloading smbd session process group membership cache
So the problem is that smbd session processes will forever cache the POSIX group memberships that the logged in user possesses. Consider a following example: *smb.conf: * [share_a] path = /mnt/a valid users = dude *ls -l /mnt:* drwxrwxr-x root group_a a */etc/group:* group_a:*:2000:user Now, a client mounts *share_a* as *dude* and has R/W access to it via his *group_a* group membership. Then, without unmounting the share, we add another share and HUP smbd. *smb.conf: * [share_a] path = /mnt/share_a valid users = dude [share_b] path = /mnt/share_b valid users = dude *ls -l /mnt:* drwxrwxr-x root group_a share_a drwxrwxr-x root group_b share_b */etc/group:* group_a:*:2000:user group_b:*:2000:user Now, the same client is able to mount the new share, but can't write to it since to its cached knowledge, *dude* is not a member of *group_b* since he wasn't one at the time of connection. What I'm looking for is a way to tell smbd to flush membership cache without resorting to killing it.
Jeremy Allison
2019-Feb-22 16:58 UTC
[Samba] Reloading smbd session process group membership cache
On Tue, Feb 19, 2019 at 06:13:09PM +0100, Eugene Pankov via samba wrote:> So the problem is that smbd session processes will forever cache the POSIX > group memberships that the logged in user possesses. Consider a following > example: > > *smb.conf: * > [share_a] > path = /mnt/a > valid users = dude > > *ls -l /mnt:* > drwxrwxr-x root group_a a > > */etc/group:* > group_a:*:2000:user > > Now, a client mounts *share_a* as *dude* and has R/W access to it via his > *group_a* group membership. > Then, without unmounting the share, we add another share and HUP smbd. > > *smb.conf: * > [share_a] > path = /mnt/share_a > valid users = dude > > [share_b] > path = /mnt/share_b > valid users = dude > > *ls -l /mnt:* > drwxrwxr-x root group_a share_a > drwxrwxr-x root group_b share_b > > */etc/group:* > group_a:*:2000:user > group_b:*:2000:user > > Now, the same client is able to mount the new share, but can't write to it > since to its cached knowledge, *dude* is not a member of *group_b* since he > wasn't one at the time of connection. > > What I'm looking for is a way to tell smbd to flush membership cache > without resorting to killing it.You have to terminate the connection from that client and have it reconnect. We don't have a way of dynamically chaning credentials on existing connections.
Eugene Pankov
2019-Feb-22 17:11 UTC
[Samba] Reloading smbd session process group membership cache
Credentials are not changed - UID/GID/SID are still the same afterwards. The user is simply being added to another group. On Fri, Feb 22, 2019 at 5:58 PM Jeremy Allison <jra at samba.org> wrote:> On Tue, Feb 19, 2019 at 06:13:09PM +0100, Eugene Pankov via samba wrote: > > So the problem is that smbd session processes will forever cache the > POSIX > > group memberships that the logged in user possesses. Consider a following > > example: > > > > *smb.conf: * > > [share_a] > > path = /mnt/a > > valid users = dude > > > > *ls -l /mnt:* > > drwxrwxr-x root group_a a > > > > */etc/group:* > > group_a:*:2000:user > > > > Now, a client mounts *share_a* as *dude* and has R/W access to it via his > > *group_a* group membership. > > Then, without unmounting the share, we add another share and HUP smbd. > > > > *smb.conf: * > > [share_a] > > path = /mnt/share_a > > valid users = dude > > > > [share_b] > > path = /mnt/share_b > > valid users = dude > > > > *ls -l /mnt:* > > drwxrwxr-x root group_a share_a > > drwxrwxr-x root group_b share_b > > > > */etc/group:* > > group_a:*:2000:user > > group_b:*:2000:user > > > > Now, the same client is able to mount the new share, but can't write to > it > > since to its cached knowledge, *dude* is not a member of *group_b* since > he > > wasn't one at the time of connection. > > > > What I'm looking for is a way to tell smbd to flush membership cache > > without resorting to killing it. > > You have to terminate the connection from that client > and have it reconnect. > > We don't have a way of dynamically chaning credentials > on existing connections. >
Possibly Parallel Threads
- Reloading smbd session process group membership cache
- Reloading smbd session process group membership cache
- Share permissions
- Samba 3beta3 - Winbind and groups in groups - question
- Simple General Statistics and R question (with 3 line example) - get z value from pairwise.wilcox.test