Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<script type="shell"> to execute arbitrary shell commands, and import stdout or result written to local file as a JavaScript module #3443

Closed
guest271314 opened this issue Feb 2, 2018 · 10 comments

Comments

@guest271314
Copy link
Contributor

commented Feb 2, 2018

Note, this is just a concept that have been mulling over for a few months. Given

<script type="shell" src="file:///home/USER/.config/SHELL_SCRIPTS/ls.sh"></script>

or

<script type="shell">
#!/bin/bash
touch export.txt
ls -l > export.txt
</script>

or

<script type="shell, module">
#!/bin/bash
touch export
ls -l > export

# some mechanism to export the result of `stdout` or created local file "export.txt" as a JavaScript "module"
</script>
<script type="module"> import {stdout} from "./export" </script>

This is a concept roughly based on Native Messaging available at Chromium and Firefox browsers.

We could provide some form of notification to the user where permission is either granted or not (similar to navigator.getUserMedia(), navigator.registerProtocolHandler(), etc.) for a given local folder either containing the binary itself or having adequate permissions to be executed as a program; and sandbox the permissions to the specific folder to avoid permission escalation concerns.

We could also create some form of wrapper for stdout of the command(s) or fetching of a temporary created file for the purpose of using export {<export result of shell command here as JavaScript module>}.

Has this concept or inquiry been previously presented to and considered by HTML Standard?

What is the viability, and security considerations of adding "shell" to <script> element type to execute arbitrary shell commands where src requests resources from file: protocol?

@guest271314 guest271314 changed the title <script type="shell"> to execute arbitrary shell commands, stdout and import the result <script type="shell"> to execute arbitrary shell commands, and import stdout or result written to local file as a JavaScript module Feb 2, 2018
@domenic

This comment has been minimized.

Copy link
Member

commented Feb 2, 2018

I don't think any browser is interested in introducing new languages to the web, such as bash.

@guest271314

This comment has been minimized.

Copy link
Contributor Author

commented Feb 2, 2018

The concept does not intend to introduce a new language to the web. The concept is based on allowing execution of existing binaries already available at the user OS, and wrapping stdout as a JavaScript module which can be imported as a JavaScript module. The execution of the binary would occur at the OS level. Perhaps utilizing WebAssembly Language virtual machines #535 or other means internally to achieve the requirement.

@guest271314

This comment has been minimized.

Copy link
Contributor Author

commented Feb 2, 2018

The user could configure the sandboxed environment for the specific commands which are authorized, for example excluding rm; though the language used at the OS could be any binary, PHP, python, C++, etc. We would not allow, for example, external resources to be requested.

We can already do this using Native Messaging. The concept is to allow the same procedure at <script type="shell"> element.

@guest271314

This comment has been minimized.

Copy link
Contributor Author

commented Feb 2, 2018

@domenic Have certainly not worked out all of the details, nor even composed a POC specific to parsing a <script type="shell"> element. Just sharing a concept. It took quite some time for this user to gather the proper usage of Native Messaging protocol for the ability to call a single binary from a Chrome App - without starting a local server and GET or POST.

HTML has used type other than "application/javascript" in the past; i.e.g. 18 Scripts, and am curious if that implementation could be revisited within the current era of HTML.

If the concept is not viable at <script> element whatsoever will explore other options to run local commands within a sandboxed environment from HTML without using an "app", extension or local server, then formatting the output for the ability to import the result of the command as a JavaScript module.

Is the concept not viable?

@domenic

This comment has been minimized.

Copy link
Member

commented Feb 2, 2018

In general I don't think breaking out of the web sandbox and running binaries on a user's OS is something we want to allow at all. It drastically breaks the web's security model. Using a cooperating local server, which the user has to install via out-of-band trusted channels, is the canonical way to do this.

@guest271314

This comment has been minimized.

Copy link
Contributor Author

commented Feb 2, 2018

Fair enough. Suppose was trying to avoid manually opening terminal to start the local server; and manually stopping the server when that particular tab or browser instance itself was closed. Possibly using Chromium --proxy flag, though uncertain how to tie the browser instance to starting and stopping the local development server, which is more than likely beyond the scope of this issue.

Not sure if it is possible to somehow use the existing Native Messaging implementation as an underlying process of the present concept - again, without specifically using the Chrome App to achieve the same.

In any event, your feedback is helpful.

@annevk

This comment has been minimized.

Copy link
Member

commented Feb 2, 2018

Yeah, this is out-of-scope. Not really sure what a viable place would be to have this discussion, sorry.

@annevk annevk closed this Feb 2, 2018
@sashafirsov

This comment has been minimized.

Copy link

commented Feb 6, 2018

The access to native apps and OS resources been presented in HTML from very beginning. HTA stands for HTML application and was available in IE up to now. Similar approach been considered by other browsers.
The shell is not something which comes out of the box but with ability to run any executable and trapping std streams by JS, it is not a showstopper. I have used this approach back in 2006 in commercial cross-platform CDs for DOCSIS modem provisioning. Of course there was no unified standard, but was doable. Modern browsers are bit more restrictive and it creates the challenge to make HTML-based native app.

@annevk , the type=bash has sence only in context of HTML application(not as web page). Should this subject be addressed in such context?

@annevk

This comment has been minimized.

Copy link
Member

commented Feb 16, 2018

@sashafirsov maybe; that would go counter to the cross-platform nature of HTML and is therefore out-of-scope here.

@guest271314

This comment has been minimized.

Copy link
Contributor Author

commented Feb 16, 2018

@annevk How exactly would adding a type="<scripting language>" be counter to the cross-platform nature of HTML?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.