New SMB2/3 features and SMB_VFS_* and connection_struct...

[simo]

On Mon, 2012-05-28 at 20:20 +0200, Stefan (metze) Metzmacher wrote: 
> Hi,
> 
> 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:-)

I see how you become the desired user, but there is no way to go 'back'.
This seem to imply you cannot mix tevent_impersonate with any other
tevent call, as the process will change user and will not change it back
once done.
Where is the trick/technical detail I am missing ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>