Impersonation on Windows on a per-interpreter basis
pal...@yahoo.com
particular user account so that all resource access by that thread
will use the credentials/rights of that user. I was wondering whether
the same might be possible in a Tcl application with an interpreter
dedicated to a user. So for example, when my server process accepts a
remote connection and authenticates the Windows credentials for a
remote user, I would do an 'interp create', followed by an
impersonation call within that interp using the user's credentials.
Thereafter, all Tcl commands within that interpreter would be under
that user's context. Different interps would potentially be running
under different user contexts.
TWAPI already supports the underlying Win32 API for impersonation. My
question is - how feasible would it be to hook into the interpreter
infrastructure such that whenever switching between interps, the core
(or an extension) would switch impersonation contexts? This would also
have to take into account, callbacks from events, asynch i/o, Tk
messages etc.
Any comments ? (assuming the above is clear enough in terms of what
I'm trying to achieve)
/Ashok
pal...@yahoo.com
Wojciech Kocjan
napisał(a):
> A common paradigm in Windows is to have a thread impersonate a
> particular user account so that all resource access by that thread
> will use the credentials/rights of that user. I was wondering whether
> the same might be possible in a Tcl application with an interpreter
> dedicated to a user. So for example, when my server process accepts a
> remote connection and authenticates the Windows credentials for a
> remote user, I would do an 'interp create', followed by an
> impersonation call within that interp using the user's credentials.
> Thereafter, all Tcl commands within that interpreter would be under
> that user's context. Different interps would potentially be running
> under different user contexts.
I think there's no need to do what you are asking for per interp.
You can use thread extension, create a separate thread (instead of a
separate interp) and change the context of that particular thread. That
way you also get async Windows calls if you code it the right way.
Also, it might not be possible to do it per-interp without huge
modifications in the core if your app would use events - for example a
press of a button would require the thread to change context while at the
same time getting a message from a socket would require setting it back.
I think using separate threads is much more powerful.
--
Wojciech Kocjan
pal...@yahoo.com
> Also, it might not be possible to do it per-interp without huge
> modifications in the core if your app would use events - for example a
> press of a button would require the thread to change context while at the
> same time getting a message from a socket would require setting it back.
>
> I think using separate threads is much more powerful.
>
> --
> Wojciech Kocjan
This is exactly why I posted. Nevertheless, I was hoping there might
be just a couple of places in the core where an "interp switch" takes
place where one could conceivably hook in the impersonation calls.
Going with threads would probably be easier except I tend to prefer
sticking with an event based model, for performance/scalability
reasons.
/Ashok
Wojciech Kocjan
napisał(a):
> On Oct 22, 9:40 pm, "Wojciech Kocjan" <wojciec...@gazeta.pl> wrote:
>> Also, it might not be possible to do it per-interp without huge
>> modifications in the core if your app would use events - for example a
>> press of a button would require the thread to change context while at
>> the
>> same time getting a message from a socket would require setting it back.
>>
>> I think using separate threads is much more powerful.
> This is exactly why I posted. Nevertheless, I was hoping there might
> be just a couple of places in the core where an "interp switch" takes
> place where one could conceivably hook in the impersonation calls.
I sincerely doubt it. That could perhaps be done using traces on command
execution, but it would put some overhead.
> Going with threads would probably be easier except I tend to prefer
> sticking with an event based model, for performance/scalability
> reasons.
You can use [thread::send -async] to send/receive events from the child
thread. That way you could treat each impersonation as a job queue you
communicate with. It's actually quite convenient model for many cases.
--
Wojciech Kocjan
Gerald W. Lester
In that case when you process an event, part of the stored context
information has to be the user. You then issue the calls to change to that
user. At the end of that event processing block you change back to your
"server" user.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+