Re: Strange permissions issues calling 'shell' in Windows

[Monte Goulding via use-livecode]

> On 31 Oct 2017, at 9:40 pm, Ben Rubinstein via use-livecode 
>  wrote:
> 
> 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?

LiveCode’s shell function on windows is basically telling cmd.exe to run the 
command. I have run into permissions issues before on school networks that have 
policies that block the use of the command prompt. In that case moving to open 
process with a read from process loop worked around the policy. You might try 
that. It could be in the scheduled task environment there is something missing 
that cmd.exe needs.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Strange permissions issues calling 'shell' in Windows

[Mike Bonner via use-livecode]

nvm my response, my earlier message poofed due to size. *sigh* here goes
again...

one thing you might try is to look at the properties for the scheduled
job.  You obviously have it set to "run whether user is logged in or not"
but i'm wondering if "do not store password" box is checked. If it is,
might test with it unchecked.  there is also a box for "use highest
permissions" that you might try if the first idea fails.

disclaimer:  I have no idea how this would affect machine security.

Also, there is a button that allows you to change user or group, I don't
know how to do so, but if you can give a group permission to run pslist,
and then set the task to that group, that might be a way also.

Here is the screen i'm looking at for all this...
https://www.dropbox.com/s/0chbhqcn8hi4cu1/image%20%281%29.png?dl=0

On Tue, Oct 31, 2017 at 10:32 AM, Mike Bonner  wrote:

> i'm on 10, no clue what earlier versions would look like.
>
> On Tue, Oct 31, 2017 at 10:23 AM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Windows 10?
>>
>> Bob S
>>
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Strange permissions issues calling 'shell' in Windows

[Mike Bonner via use-livecode]

i'm on 10, no clue what earlier versions would look like.

On Tue, Oct 31, 2017 at 10:23 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Windows 10?
>
> Bob S
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Strange permissions issues calling 'shell' in Windows

[Bob Sneidar via use-livecode]

Windows 10?

Bob S



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Strange permissions issues calling 'shell' in Windows

[Ben Rubinstein via use-livecode]

Hi Bob,

Thanks for taking the trouble to consider this.


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. 


It isn't that, the file is being created, the output from pslist.exe is being 
written to it - but the output is the report from pslist.exe saying that it 
didn't have permission.



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).


The scheduled task is set to use the same account as I use to log in.

I thought that the issue was the difference between being logged in as this 
account, and the task running with the same account. But it isn't (just) that, 
because when I made the scheduled task a batch script to run the command, it 
worked.


So there is an additional difference imposed by using an LC app using 'shell' 
to run the command, rather than using a batch script. Both work fine when 
logged in; only one when it is a scheduled task. The command works fine 
invoked from a batch script which itself is run as a scheduled task. But the 
command reports the permission problem when it is invoked from the app running 
as a scheduled task.


Ben


On 31/10/2017 14:57, Bob Sneidar via use-livecode wrote:

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 
 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 

Re: Strange permissions issues calling 'shell' in Windows

[Bob Sneidar via use-livecode]

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 
>  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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Strange permissions issues calling 'shell' in Windows

[Ben Rubinstein via use-livecode]

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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode