System Call Access for UXP

@pklaschka @Velara you guys both have totally valid points, however, this conversation is getting completely derailed from the proposed topic. Probably best to start a topic on permissions and continue this conversation there.

My main point is that any type of permissions solution (be it one screen, agree-as-you-go, etc) can work in this case and doesn’t stand in the way of integrating system call capabilities into UXP, a feature that is used in tons of CEP panels at the moment and will need to be addressed before CEP is discontinued.

3 Likes

While I agree that this isn’t the place for a dicussion solely about a permission system, it – to me – is an important aspect of this feature request, since it basically means that I “vote” for the request under said conditions for a permission system associated with it. Therefore, while an extensive discussion about the implementation of such a system would be out of place here, I tend to disagree that the conversation is getting completely derailed from the proposed topic – this simply is an integral part of such a feature and therefore (in my opinion) does – to a degree – belong here (especially since a permission system is only relevant in conjunction with features like this and therefore isn’t a feature request by itself) :wink: .

The thing is that I absolutely agree that such a feature is required for the API, but potential risks, ways around those risks and other aspects of such a feature do – in my opinion – belong here (and therefore also the permission system discussion).


Getting to another aspect of this: When should a plugin be allowed to make system calls?

What I mean is: Should those calls only get executed by plugins during the “editing timeframe” (i.e. the time when the plugin may also do changes to the scenegraph)? This gets especially important when panels “become a thing” in UXP and therefore, the question about when a plugin executes gets less and less “black and white”. One way to add a security layer (the question is whether this restricts this feature too much) would be to only be able to execute those requests on explicit user interaction (i.e., running the plugin) like we currently have for scenegraph manipulations.

If – however – such a restriction were be too restrictive (I – of course – don’t know all the use-cases), I think it would be wise to have an additional required permission of “running system resources from the background” (or something similar) to add transparency for users.

2 Likes

OMG. When this come into Photoshop… Thanks god I am working in private sector so I can use custom .exe installer same as now and run external app in different ways. And skip all these security things if needed. I think that I will prefer work for private sector than for publicly sell plugins to everyone. There is so many pros.

1 Like

Systems commands are an absolute need.
On InDesign thev’e been available for the past 20 years, PS too.
Calling libraries like imageMagik, ffmpeg and custom commands is basic and essential stuff.
Please don’t kill off the scripting community by tying their hands so much.
The answer to all these security issues is permissions

3 Likes

External processes would have their own system permissions, so security should not be an issue.

Running processes and passing data back and forth is essential.

1 Like

Hey all,

Thanks for all the great discussion thus far, and I look forward to lots more discussion in the future.

Do note that we’ve never said that there would be no option to access external processes. What we do need to be careful about are these things:

  1. Security and Privacy. A trusted ecosystem is a win for everyone involved – Adobe, customers, and developers alike. The safety and privacy of the user is paramount. Users shouldn’t have to worry whether installing a plugin can harm their machine – intentional or not. Now I understand that we can’t be perfectly secure and accomplish actual work, but security and privacy are things about which we must address, and which we must address carefully. To ignore the potential for abuse or misuse is to misplace the trust of all of our users (yours and ours). Once a user is burned by one plugin, they may elect not to to trust other plugins. That would be disastrous for everyone involved.

    Also, we’re not raising security and privacy just because we fear malicious actors in the ecosystem. The truth is that it’s trivial to do bad things by accident. The history of computing is littered by all sorts of apps that in certain edge cases managed to delete all the files on a volume. Making that a little harder to do by accident is not a bad thing.

  2. User Experience. How many times have you launched, say, Visual Studio Code or Chrome, or some other app, only to have a million “Helper” processes sucking the life out of your computer? This isn’t a great experience for anyone involved, and we need to think carefully about that. Arbitrary processes that are outside the host’s control make it more difficult to ensure a consistently good user experience. We have to carefully think about how to make it hard for a developer to end up in a bad state where they can’t terminate a process they started, for example. This means thinking very carefully about the API design itself.

  3. Cross-platform and OS version capabilities. Yes, not everyone will want to write a plugin that works on every supported platform, but I think it’s pretty amazing that all but two Adobe XD plugins in the Plugin Manager work on both Windows and macOS, and every supported version as well. Obviously this is also possible with a web browser and even Node, but once you start executing external processes, you’re at the mercy of the operating system itself and how the user has configured it. Apple loves to remove common utility functions on a whim, which means you can never quite be sure your external process will actually work. (A slightly different but not unrelated issue is that of spawning your own processes from binaries bundled with the plugin – you know these exist, but you also have to compile them for each platform.)

All that said, the capability of launching external processes has never been off the table. What we’re considering is the best way forward that doesn’t compromise the user’s security or experience. Furthermore, where the current practice is to launch an external process to do something around, say, licensing, we think maybe there’s better ways to accomplish that by providing a better API. What we want to do is to make a world-class API surface that makes it easy to create amazing and compelling experiences for all of our customers. UXP has never been about taking things away. It’s about providing a great API that empowers developers to do amazing things.

Okay, so what is the ability to launch an external process apt to look like? Well, we don’t know yet. We’re thinking about it, and even working up UX ideas about how that might look, and that’s why we value these discussions.

Lastly, it may seem like we’re missing critical APIs that CEP provided, but this is version 1 of UXP. UXP isn’t done growing or maturing. We’ve got lots of ideas planned for it in the future, and we want it to be a vital platform that leads to amazing things, but we also want to make sure that the platform has a stable foundation as well, and that means thinking carefully about every brick we place.

8 Likes

Will y’all do any post-MAX thinking about this? It’s pretty important.

We’re working on a permissions API that will enable the launching of external apps and documents. That should be out early 2020 (a fast-ish-follow).

2 Likes

Fantastic news! Thanks for giving this some priority.

Hi :wave:

Is there any progress on this topic? A UXP API that would allow launching external apps?
We would like to execute an optimized C++ algorithm - ideally a common solution for XD and Photoshop.

Thanks

2 Likes

Is this effort dead? :frowning:

I’ve developed extensive plugin for our team that massively helps with our workflow and automates tons of actions. Of course, it relies heavily on 3rd party scripts / encoders / applications.

The team has migrated to M1 chips and surprise surprise, the CSXS plugin is no longer supported. The only option is to use Rosetta version with 50% performance loss.

At least you could have enabled some debug mode or something for internally developed (trusted) plugins. Really, nothing after 2 years? :frowning:

What exactly is UXP good for besides hiding and naming layers?

1 Like

Would like to bump this issue as well.

I know we can launch external apps and communicate with them via WebSockets, but this does require a fair amount of extra work that’s not typically needed for interacting with an external command line tool like FFMPEG and others. Are there any plans to support system call access for UXP? Thanks!

1 Like

so? Is there no progress on this issue? It took three years

1 Like

bump

Seems like there was a lot of effort and momentum behind this. Would love to see this conversation continued.

1 Like

A note on the permissions thing.

Based on modern permission trends it would go like this:

  • app is installed no special permissions requested or given
  • when you need a special permission an dialog is presented where you can ask the user for permission. the user can grant permission or deny it and they can change it later in the settings window
  • the plugin receives an event with the results of the request.
    a user can see when a permission is needed and grant it at the time it’s needed once or for all

now the additional descriptions are from browser land:

  • when you use the special permission an permission disclosure icon appears in the browser title bar. if you grant video access the video icon appears when it is being used. this is for the sake of the user. the same should be available for any permission granted. in the web inspector tool, cmd+shift+i, when a request is sent you can see the request in the network monitor and what is being sent.

this sortof approach seems the way apple, google and browser makers have been going

1 Like

A lot has changed since 2019. I’ve posted my updated proposal in the Adobe Devs Slack but cross posting here as well:

UXP CLI Command Proposal

The Problem:

Executing CLI Commands (Command Prompt / Terminal) in UXP panels currently requires developers to build, sign, notarize, and ship binaries for each platform and call them with uxp.shell.openPath() even if all they are trying to accomplish are simple / one-liner commands.

The Solution:
An equivalent to child_process.exec() / child_process.execSync() in Node.js / CEP but for UXP, but with improved security.

Potential Code Examples:

const { exec, execSync } = require('uxp');
const res = execSync('echo helloSync'); 
console.log(res); // "helloSync"

exec('echo helloAsync', (err, stdout, stderr) => { 
    console.log(stdout); // "helloAsync" 
})

Permission & Security Concerns:

  • A CLI command can do anything a shipped binary can, so permissions of each are roughly the same.
  • However, an app that can access the command line and internet is always a security concern and can be subject to remote code execution vulnerabilities.
  • A possible solution for this is to disallow code generation to be used in exec / execSync the same way that "allowCodeGenerationFromStrings": true currently works in Manifest v5.
  • A list of allowed commands could be included in the manifest like so:
{
    "allowedCommands" : [
        "echo", "ffmpeg", "gimp", "setx" 
    ]
}

Use Cases:

  • Gathering system info needed for plugin such as system specs, network settings, managing environment variables.
  • Running CLI tools like ffmpeg, gimp.
  • Accessing a developer’s custom licensing framework.

I think adding this feature in some form would be an enormous relief for devs as this was one of the large concerns that arose in the community when UXP was announced alongside filesystem and webview which I’m happy to see are making progress since the start of UXP.

Thank you!

7 Likes

Hi guys, any update on this?

1 Like

@pkrishna mentioned in Slack that they were going to bring this up in an internal meeting.

Also interested if there has been any progress here.

3 Likes

Even though UXP Hybrid Plugins now exist, all we would be doing is writing our own execSync(). We are still very interested in a UXP CLI as proposed here without having to take on the overhead of compiling a C++ plugin for the sole purpose of calling external tools required in a studio environment. Any thoughts as to something like this UXP CLI proposal happening? Thanks!

1 Like

I very much agree with @joshy. We actually went the route of implementing a C++ hybrid plugin for this purpose but ultimately would love a more integrated solution that comes with UXP right away. I also think it would lower the bar for pipeline integration in a VFX/animation setting, where this kind of thing is currently a major obstacle.

2 Likes