You can register your test as a service to be able to run it as SYSTEM. A bunch
if Wine's tests do this, e.g. advapi32:service and services:service.
To solve the other problem, one option might be to inject a thread into the
spooler process and run your test code there. Not sure if we already have code
to do this anywhere though.
On June 7, 2015 1:56:39 PM CEST, Colin Finck <co...@reactos.org> wrote:
>Hi all,
>
>In order to verify the exact behaviour of localspl.dll on Windows
>Server
>2003, I'm trying to write an API-Test for it. This is no problem for
>winspool.drv or even the Print Processor functions of localspl.dll, but
>its Print Provider functions pose some serious problems:
>
>* You get a table of function pointers by calling
>InitializePrintProvidor.
>
>* Instead of just handing over the pointers, this function first calls
>many undocumented ones from spoolss.dll, including CacheAddName,
>CacheCreateAndAddNode, GetServerPolicy, SplInitializeWinSpoolDrv,
>SplIsUpgrade.
>
>* Out of these undocumented functions, GetServerPolicy is the most
>problematic one, because it itself relies on a function pointer given
>by
>spoolsv.exe to spoolss.dll in an initialization function. My API-Test
>is
>not spoolsv.exe, so I don't initialize spoolss.dll the same way. Thus,
>GetServerPolicy will fail and InitializePrintProvidor as well.
>
>* For now, I worked around this problem by stubbing these functions in
>my spoolss.dll. I.e., GetServerPolicy just returns TRUE there and I get
>further.
>
>* On top of this, InitializePrintProvidor also makes use of
>RevertToPrinterSelf and ImpersonatePrinterClient. To let these
>functions
>succeed, the current thread actually needs to impersonate a user. For
>now, I worked around this problem by doing:
>
> OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE, &hToken);
> DuplicateToken(hToken, SecurityImpersonation, &hDup);
> ImpersonateLoggedOnUser(hDup);
>
>before calling InitializePrintProvidor.
>
>* Finally, this lets InitializePrintProvidor succeed and it gave me the
>table of function pointers.
>Unfortunately, even simple query functions like fpEnumPrinters do a
>RevertToPrinterSelf and then expect to be in the SYSTEM context of
>spoolsv.exe. When my API-Test was just run in a usual Administrator
>user
>context under Windows Server 2003, fpEnumPrinters didn't succeed.
>For now, I worked around this problem by running my test program as a
>service in the SYSTEM context.
>
>
>With all these problems presented, can you think of any way how I can
>now write a reliable API-Test for localspl.dll that could be run
>regularly under Windows Server 2003 and ReactOS?
>
>One idea would be to load the system spoolss.dll and then rewire the
>GetServerPolicy import to a function that just returns TRUE all the
>time.
>Still then, I have the problem that my API-Test would need to be run in
>the SYSTEM security context.
>
>Creative ideas are welcome! :)
>
>
>Cheers,
>
>Colin
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev@reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
