Strange permissions issues calling 'shell' in Windows

Bob Sneidar bobsneidar at iotecdigital.com
Tue Oct 31 10:57:03 EDT 2017


The first thing that comes to my mind is, where are you putting the log file? If you are using a specialfolderpath that only has a context when logged in, then that might be an issue. As far as the firewall goes, unless you or your IT team has intentionally blocked RPC traffic, it should have an exception by default, as a lot of things use this service. Now if you are logged off, I am not sure what account is being used to access the registry (and am not sure why it's accessing it or why you would want to in the first place). 

Bob S


> On Oct 31, 2017, at 03:40 , Ben Rubinstein via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I have an app in LC, which normally runs as a nightly scheduled task on a VM in the client's network.
> 
> It's been having memory problems, and to help diagnose this I wanted to track memory usage through the job and over time (it runs every night, takes about 40 minutes crunching lots of data, and emails me a log after each run).
> 
> Unfortunately LC doesn't have any reliable ways to inspect its memory usage, so I've been trying to use a combination of an LC function that estimates the size of all global variables, with a shell call to the 'pslist' sysinternal tool.
> 
> Run 'live', this works fine. But when run as a scheduled task, logged out of the machine, instead of the expected process information the result of the shell call was
> 	Failed to take process snapshot on ORGAPP01.
> 	Make sure that the Remote Registry service is running on the remote
> 	system, that you have firewall ports allow RPC access, and your
> 	account has read access the following key on the remote system:
> 	HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib
> 
> I don't have that kind of access (nor the Windows knowledge to use it safely if I did!) so I appealed to the client's IT dept, who said some words I didn't understand to the affect that it should work. When I said again that it worked logged-in, but not as a scheduled task, they asked for details of the batch file; so I thought the simplest thing would be to set up a simple batch file to demonstrate the issue.
> 
> I made a batch file to invoke pslist and put the result in a text file; it worked. Then I made a scheduled task to invoke this batch file, expecting it to fail with the above issue thus proving my point and giving the IT guy a test case to work with - but in fact when the scheduled task ran, the output from pslist was perfectly good.
> 
> So then I thought that this was a work-around: instead of my app using shell to invoke pslist and then log the result of the shell call; it could instead use shell to invoke the batch file, and then read back and log the contents of the output file generated by the batch file.
> 
> So I made the change in the app, moved it over, ran it with the expected and desired result; logged out and waited.
> 
> This morning however I got the same error message as before in the log.
> 
> So the situation is:
> 	1) logged-in app uses shell to call pslist: OK
> 	2) not logged-in app uses shell to call pslist: permissions error
> 	3) logged-in batch file calls pslist: OK
> 	4) not logged-in batch file calls pslist: OK
> 	5) not logged-in app uses shell to call batch file which calls pslist: permissions error
> 
> 
> If step (4) produced a permissions error, I'd be sort-of happy. If step (5) worked, I'd be even happier. But it's the distinction between (4) and (5) that puzzles me.
> 
> Is there some way that calling 'shell' enters a context with less permission than the app which calls it? And is there something I can do about this?
> 
> TIA,
> 
> Ben
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list