connection_struct.txt

diff --git a/connection_struct.txt b/connection_struct.txt
new file mode 100644 (file)
index 0000000..df7f986
--- /dev/null
+++ b/connection_struct.txt
@@ -0,0 +1,74 @@
+
+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()
+function pair.
+
+We currently have the introduction of
+struct smbXsrv_session[_global],
+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 handles.
+
+See also:
+https://wiki.samba.org/index.php/Samba3/SMB2
+https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-reauth
+https://www.samba.org/~metze/presentations/2012/obnox_metze_sambaxp2012_smb2-in-samba-handout.pdf
+
+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 SMB_VFS_CLOSE
+    (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 operating
+    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
+    smbd_calculate_access_mask()
+
+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.
+See
+https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-impersonate
+
+Comments, please:-)