29 May 2012 16:47
Re: New SMB2/3 features and SMB_VFS_* and connection_struct...
simo <idra <at> samba.org>
2012-05-29 14:47:37 GMT
2012-05-29 14:47:37 GMT
On Tue, 2012-05-29 at 15:56 +0200, Stefan (metze) Metzmacher wrote: > Am 29.05.2012 15:21, schrieb 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 ? > > We have 3 tevent_context structures, but two are just wrappers, > which inject a handler function in order to impersonate before > calling the real handler. > > tevent_loop_once/_wait will call smb_panic() if called via the wrappers. > > Did you get what I mean? Yes, makes sense. I wonder if we shouldn't make this wrapping functionality a standard feature of tevent. Not the impersonation specific feature, just the wrapping part. Simo. -- -- Simo Sorce Samba Team GPL Compliance Officer <simo <at> samba.org> Principal Software Engineer at Red Hat, Inc. <simo <at> redhat.com>
> >>>
> >>> 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 ?
>
> We have 3 tevent_context structures, but two are just wrappers,
> which inject a handler function in order to impersonate before
> calling the real handler.
>
> tevent_loop_once/_wait will call smb_panic() if called via the wrappers.
>
> Did you get what I mean?
Yes, makes sense.
I wonder if we shouldn't make this wrapping functionality a standard
feature of tevent. Not the impersonation specific feature, just the
wrapping part.
Simo.
RSS Feed