Samba: Connected clients unaffected by group/share/user access changes

Question

We are trying to solve what we perceive as a problem with the behavior of our Samba server. Please understand we are not claiming this is a bug in Samba. It is simply different from the behavior we want.

Our Samba server is version 3.5.4 (release 68.el6) and runs under CentOS 6.0 (x86_64). We happen to use Active Directory (AD) to authenticate, but I’m not convinced this behavior is specific to AD.

What follows is a generalized statement of the undesirable behavior, with the context provided first as a sequence of events:

1. A CIFS client establishes (and maintains) a connection to a CIFS share on our Samba server.
2. After that connection has been established, a configuration change is made (examples provided as bullets below) which we think should immediately revoke the CIFS client's access to the connected CIFS share. For example:
   • The Active Directory user is deleted from the domain (via the Active Directory Administrative Center on the domain controller).
   • The Active Directory user is removed from the CIFS share's list of permitted users (on the Samba server host).
   • The CIFS share is deleted (on the Samba server host).

Here’s the undesirable behavior. As long as the CIFS client maintains the existing connection to the CIFS share, access to that share is not revoked. That is, the user continues to have the same access to the share as they did when the connection was first established. FWIW, we believe this behavior is by design.

The desired behavior is for access to be revoked as soon as “the configuration change” pertinent to access rights is finalized. Disconnecting the affected client session(s) is acceptable and appropriate, but disconnecting other sessions is undesirable.

I would like to get your ideas toward an approach that will yield the desired behavior. Perhaps this is as simple as changing our Samba server’s configuration; we have not found any configuration parameters that appear relevant to this behavior. It appears the art of detecting that access has been revoked is the most difficult part of all this.

Answer 1

I think this is normal behavior in Linux as processes inherit their environment when they are spawned. Also I think if Samba had to check for things like this especially over the network if you're using AD then it would be so slow that it would not be usable.

So after such a change you should be able to kill the appropriate smbd process. To locate the appropriate process run smbstatus -p | grep <username>. The first column of numbers in the results are the process PID. Which you can then kill. Using kill -9 <PID> if you need to force the kill to happen right away.