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

[simo]

On Tue, 2012-05-29 at 14:23 +0200, Stefan (metze) Metzmacher wrote: 
> Hi Simo,
> 
> >> 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 ?
> 
> Currently 'smbd' also changes the user only if needed.
> It doesn't change back to root in every event loop.
> There're explicit 'change_to_root()' calls if really needed.
> 
> That's why we'd have 3 types of tevent_context pointers:
> 1. the raw tevent_context that doesn't do any impersonation
> 2. a tevent_context that runs the handlers as root
>    tevent_change_to_root()
> 3. a tevent_context that runs as the correct user
>    tevent_change_to_user(),
>    Note: that this also needs to call set_current_service()
> 
> And I think the SMB_VFS modules should only have access to 3.

Hmm if you are using a different tevent context, doesn't it mean we will
not be fully asynchronous ?

If we are looping in the 'impersonation' context and a file descriptor
becomes ready for reading in the raw context, then we will not server
the one in the raw context until we return back from the loop handling
the impersonation context ?

The same is true in reverse also ?

Isn't there a risk of starvation here ?
What about interactions between code that run in 2 different context ?

Simo.

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