Windows: Uploaded binaries cannot be executed

Attaching a binary file to the project on the Windows platform should behave similarly to Linux, in which that given the correct permissions on the file it should be executable by the Lambda server (or similar Serverless binary compatible server)

A workaround for this issue is to use Bash for Windows to zip the project (with the file given 777) and upload manually

• What did you expect should have happened? The file attached should be executable by Lambda (or similar Serverless binary compatible server)

Although I expect it to be executable the way Windows defines what is/is not executable is different to Linux, so the permissions on the file may be harder to utilise, a proposed idea is to have a configuration file marking files/folders as executable

• What was the config you used? N/A
• What stacktrace or error message from your provider did you see? [Error: spawn EACCES] code: 'EACCES', errno: 'EACCES', syscall: 'spawn' when trying to launch the process

Similar or dependent issues: #1631

Proposed solution

(Added by maintainers after investigating the matter)

1. As proposed below in https://github.com/serverless/serverless/issues/3557#issuecomment-315525767 by @ilanc, when packaging on Windows ensure each packaged file is executable (as we’re packaging for environment with already properly restricted access, so there seems no risks in doing that) File permissions are setup here: https://github.com/serverless/serverless/blob/03940254385e138eb40f2f25bd56fcdbee0c3a22/lib/plugins/package/lib/zipService.js#L105-L109

2. Revert tweak introduced here https://github.com/serverless/serverless/pull/5813 for golang runtime. It’s hacky and obsolete with above solution

PR’s welcome!

[Agrumas]

Some kind of workaround is really needed because go applications can not be used if deployed using win. Execution fails: { "errorMessage": "fork/exec /var/task/bin/main: permission denied", "errorType": "PathError" } executable option is good but not flexible I would suggest mode:

package:
  include:
    - some-shared-lib.js
    - sox
  mode: 0744 # change mode for all files
  mode: 
    0644:
      - sox # change mode per file

[mattisdada]

I completely agree with you, but having to build on a foreign system without a workaround feels pretty gross and mandating more complex build/deployment for it to work is painful (whereas right now you can just start working on something small and simple and get it up and running easily)

I’d say the way executable are currently being handled is equally insecure as right now it is unclear what the serverless deploy command is doing, if I was working on a developer machine to do my deployments, I would often have “looser” file permissions than I would on a normal build server/production environment, it would be easy to accidentally introduce something as too permissive

My proposed idea would be more to make everything non-executable (even if ithe file is 777 or similar on the deployment machine) unless specified in the config, if worried you could even remove globbing and just have listed files

For example:

package:
  include:
    - some-shared-lib.js
    - sox
   executable:
    - sox

It would make deployments more consistent regardless of the operating system running the deployment, and in general going out of your way to make something more permissible is often more secure (if that is a concern)