issue-#104 calling URLs and commands (InfoCmds capabilities)
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Threads is not for security! Hooks can be used for security to block any external calls.
Threads are done for not block execution of BlackBox code while external application is starting. This is essential for server mode and make better smooth behavior for regular user of BlackBox.
Threads are done for not block execution of BlackBox code while external application is starting. This is essential for server mode and make better smooth behavior for regular user of BlackBox.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
This comment was added by Josef and it related to reducing usage of any BlackBox commands inside threads. It is not related to my previous arguments about security.Zinn wrote:Sorry this line does not protect your system. Exchange in your rtf "Virus" file Open against Run and your works on Windows and Wine.Ivan Denisov wrote: IF Dialog.IsWine() THEN (* for security: prevent executing arbitrary commands including arguments *)
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
I want to make attention that Dialog.Run is not designed to be advanced tool for shell execution. It is only designed to start external applications with windows.
I see that we can later design some component for advanced shell binding.
1. It should be blocking, because user should wait for output
2. It should return results to user for further processing
For this task there should not be threads using, we should use another more complex interface and discuss many interesting things.
However the issue is not about such advanced shell tool! Please, do not try to mix the things. This issue includes only InfoCmds capabilities with asynchronous realization.
I see that we can later design some component for advanced shell binding.
1. It should be blocking, because user should wait for output
2. It should return results to user for further processing
For this task there should not be threads using, we should use another more complex interface and discuss many interesting things.
However the issue is not about such advanced shell tool! Please, do not try to mix the things. This issue includes only InfoCmds capabilities with asynchronous realization.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
What is the correct wording for the comment?Ivan Denisov wrote:This comment was added by Josef and it related to reducing usage of any BlackBox commands inside threads. It is not related to my previous arguments about security.Zinn wrote:Sorry this line does not protect your system. Exchange in your rtf "Virus" file Open against Run and your works on Windows and Wine.Ivan Denisov wrote: IF Dialog.IsWine() THEN (* for security: prevent executing arbitrary commands including arguments *)
I tried to write a comment that describes Ivan's security concerns, nothing else.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
I do not think that there should be any comments. It is just the right way how to open URL or document with Wine. So I removed this comment.Josef Templ wrote:What is the correct wording for the comment?
I tried to write a comment that describes Ivan's security concerns, nothing else.
Anyway we need to rename Open procedure, because Helmut found it confusing.
Also Robert does not agree what we did not add some dosBox for his needs. So we can change this before next revoting.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Helmut, suggest now another name for the procedure which Open URLs ans another documents, please.
I am suggesting: OpenExternal.
I am suggesting: OpenExternal.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
I don't see a dos box opening when I run as a test e.g. Dialog.Run('notepad.exe').Robert wrote:I have just tested the "Run" procedure in version 455.
I don't know enough to sensibly comment on the implementation; it seems to work fine.
But I don't like the function. It opens the "Dos Box" where the application makes some report, then closes it before anyone can read the report.
Please, can we make up our minds:
Either:
- Don't open this window
- Or let us read it
- Or give us the option.
Personally I want the option.
To keep the usual interface simple maybe Dialog could have a read/write BOOLEAN variable flag "openDosBox" which a calling application can set if it wants to. To make the procedure repeatable this flag could be automatically cleared every time Run is called.
If you use Dialog.Run('cmd.exe') then of course a dos box will open.
@Robert: Which command did you test?
- Josef
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
The procedure I currently use is but I would rather switch to the Center supported version if it did what I wanted.
An example input string (cmd) is (I observe similar issues with other applications than just LaTeX)
99% of the time I don't want the Box to open; it is just a distraction. But when there is a non obvious error in the application's input the (lengthy) report it puts into the Box contains useful debug information.
Code: Select all
PROCEDURE Start (cmd : ARRAY OF CHAR; showDosBox : BOOLEAN);
VAR
info : WinApi.STARTUPINFOW;
res : INTEGER;
proc : WinApi.PROCESS_INFORMATION;
create : SET;
dosCmd : ARRAY 256 OF CHAR;
BEGIN
WinApi.GetStartupInfoW (info);
IF showDosBox
THEN dosCmd := 'cmd /k ' + cmd; create := {}
ELSE dosCmd := cmd$; create := WinApi.CREATE_NO_WINDOW
END;
res := WinApi.CreateProcessW (NIL, dosCmd, NIL, NIL, WinApi.FALSE,
create, 0, NIL, info, proc)
END Start;
An example input string (cmd) is (I observe similar issues with other applications than just LaTeX)
I believe I ran the version 455 test with a very similar string, and observed the "Flashing" DosBox issue. I can't exactly repeat that test until this evening.latex -output-directory=D:\BlackBoxServer\Casket\Latex D:\BlackBoxServer\Casket\Latex\Graphic
99% of the time I don't want the Box to open; it is just a distraction. But when there is a non obvious error in the application's input the (lengthy) report it puts into the Box contains useful debug information.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Should we add showDosBox variable to HostDialog module or to Dialog module?
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
If we do add it, I would suggest HostDialog as I think that controlling "Dos Boxes" is a platform specific activity.Ivan Denisov wrote:Should we add showDosBox variable to HostDialog module or to Dialog module?
If the idea of suppressing or displaying the application's output makes sense on other platforms then the control variable (or other mechanism) should be in Dialog.