New SMB2/3 features and SMB_VFS_* and connection_struct...
Stefan (metze) Metzmacher
metze at samba.org
Mon May 28 12:20:58 MDT 2012
We're currently cleaning up the datastructures within
smbd in order to implement more SMB2/3 features
and prepare that VFS modules can operatate
async using a tevent_req based _send()/_recv()
We currently have the introduction of
struct smbXsrv_tcon[_global] and
struct smbXsrv_open[_global] mostly working.
Based on the new structures we have smbXsrv_session_global.tdb,
smbXsrv_tcon_global.tdb and smbXsrv_open_global.tdb to hold
the global state that is needed in order to implement
new SMB2/3 features like durable/persistent handles
and multi-channel support.
On top of the infrastructure we have dynamic reauth (needed for SMB >= 2.1)
and session reconnect (handling of previous_session_id) working
and almost ready for master.
We also have a prove of concept hacked together for durable/persistent
Currently we're trying to prepare the new structures and infrastructure
for master, while doing so we noticed a few problems and some undefined
behaviors related to the usage of VFS modules.
1. What SMB_VFS modules assume
1.1 I guess most of the vfs modules assume that the SMB_VFS_CONNECT and
SMB_VFS_DISCONNECT runs as the same user (they run as root,
but connection_struct->session_info is for the same smb session,
which means %U and others are the same).
1.2 I guess most vfs modules assume that SMB_VFS_CREATE_FILE and
(all other handle based operations) on the same fsp are called as the
same user (after a change_to_user()).
1.3 I guess vfs modules assume that the connection_struct they're
on doesn't change during an async request. The module would always
get the same information out of connection_struct->session_info
1.4 I guess vfs modules in general expect just one user session per
connection_struct, which means fsp->access_mask is correctly
checked against the connection_struct->share_access via
2. What administrators assume
2.1 I guess admins assume that "root preexec"/"preexec" and
"root postexec"/"postexec" run as the same user (at least the same %U)
It seems that none of the above is true, for smb1 if the client reuses
a tree connect for a different session, as the 'connection_struct' is reused
for all session/tcon combinations using the 'vuid cache', which just alters
'connection_struct->read_only' and 'connection_struct->session_info'.
Note: SMB_VFS_CLOSE() can run as any user (including root) depending
on the client behavior.
In order to provide a more predicable behavior (which will also allow to add
more generic async tevent_req based functions), I'd suggest that
we have one 'connection_struct' per session/tcon combination
and also remove per request data (connection_struct->case_sensitive).
We should also impersonate more correctly, so that all operations
on a file handle run as the same user, including TCP disconnects.
To do this sanely we need to have an tevent_context wrapper,
which impersonates before calling any event handler.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the samba-technical