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

[Richard Sharpe]

On Mon, May 28, 2012 at 11:20 AM, Stefan (metze) Metzmacher
<metze at samba.org> 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.

Thank you for bringing this issue up. At the moment I have one question below.

> 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

Are you proposing that the smbd/thread change to the logged in user
before any VFS function is called?

Or, are you proposing that all VFS functions are called as root and
that they change to the logged in user when and as needed. Ie, that
the guarantee is that they are always called as root?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)