connection_struct.txt

   1
   2 We're currently cleaning up the datastructures within
   3 smbd in order to implement more SMB2/3 features
   4 and prepare that VFS modules can operatate
   5 async using a tevent_req based _send()/_recv()
   6 function pair.
   7
   8 We currently have the introduction of
   9 struct smbXsrv_session[_global],
  10 struct smbXsrv_tcon[_global] and
  11 struct smbXsrv_open[_global] mostly working.
  12
  13 Based on the new structures we have smbXsrv_session_global.tdb,
  14 smbXsrv_tcon_global.tdb and smbXsrv_open_global.tdb to hold
  15 the global state that is needed in order to implement
  16 new SMB2/3 features like durable/persistent handles
  17 and multi-channel support.
  18
  19 On top of the infrastructure we have dynamic reauth (needed for SMB >= 2.1)
  20 and session reconnect (handling of previous_session_id) working
  21 and almost ready for master.
  22
  23 We also have a prove of concept hacked together for durable/persistent handles.
  24
  25 See also:
  26 https://wiki.samba.org/index.php/Samba3/SMB2
  27 https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-reauth
  28 https://www.samba.org/~metze/presentations/2012/obnox_metze_sambaxp2012_smb2-in-samba-handout.pdf
  29
  30 Currently we're trying to prepare the new structures and infrastructure
  31 for master, while doing so we noticed a few problems and some undefined
  32 behaviors related to the usage of VFS modules.
  33
  34 1. What SMB_VFS modules assume
  35   1.1 I guess most of the vfs modules assume that the SMB_VFS_CONNECT and
  36     SMB_VFS_DISCONNECT runs as the same user (they run as root,
  37     but connection_struct->session_info is for the same smb session,
  38     which means %U and others are the same).
  39   1.2 I guess most vfs modules assume that SMB_VFS_CREATE_FILE and SMB_VFS_CLOSE
  40     (all other handle based operations) on the same fsp are called as the
  41     same user (after a change_to_user()).
  42   1.3 I guess vfs modules assume that the connection_struct they're operating
  43     on doesn't change during an async request. The module would always
  44     get the same information out of connection_struct->session_info
  45   1.4 I guess vfs modules in general expect just one user session per
  46     connection_struct, which means fsp->access_mask is correctly
  47     checked against the connection_struct->share_access via
  48     smbd_calculate_access_mask()
  49
  50 2. What administrators assume
  51   2.1 I guess admins assume that "root preexec"/"preexec" and
  52       "root postexec"/"postexec" run as the same user (at least the same %U)
  53
  54 It seems that none of the above is true, for smb1 if the client reuses
  55 a tree connect for a different session, as the 'connection_struct' is reused
  56 for all session/tcon combinations using the 'vuid cache', which just alters
  57 'connection_struct->read_only' and 'connection_struct->session_info'.
  58
  59 Note: SMB_VFS_CLOSE() can run as any user (including root) depending
  60 on the client behavior.
  61
  62 In order to provide a more predicable behavior (which will also allow to add
  63 more generic async tevent_req based functions), I'd suggest that
  64 we have one 'connection_struct' per session/tcon combination
  65 and also remove per request data (connection_struct->case_sensitive).
  66
  67 We should also impersonate more correctly, so that all operations
  68 on a file handle run as the same user, including TCP disconnects.
  69 To do this sanely we need to have an tevent_context wrapper,
  70 which impersonates before calling any event handler.
  71 See
  72 https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-impersonate
  73
  74 Comments, please:-)