python / python/cpython

zipapp creates executable files with wrong permissions bits

Ouverte
#96,867 3 commentaires 0 réactions 1 personne assignée Voir sur GitHub

@pfmoore y travaille déjà.

Depuis le 30/7/2026.

stdlib type-bug
Langage dominant
Python
Étoiles
77.2k
Forks
36k
Métriques de merge des PR
Métriques de PR en attente

Description

Owing to the fact that open() has no flags field for marking a file as executable, and doing that after the fact is difficult (since it involves playing around with umask), the current implementation of zipapp uses the following code to attempt to set the file executable:

os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC)

Which is incorrect: this sets only the execute bit for the user, and will never set it for the group or "other" categories, regardless of the umask.

This was discussed in a series of comments in #96772, starting around

https://github.com/python/cpython/issues/67679#issuecomment-1093675286

Create and open executable file respecting the Unix user's umask:

os.fdopen(os.open(filename, os.O_CREAT|os.O_RDWR), "rw")

and ending with

https://github.com/python/cpython/issues/67679#issuecomment-1093675294

OK, thanks. I don't propose to go there with the initial implementation. If it's a problem in practice, someone can raise a bug and we'll fix it then. (I've never seen actual Python code in the wild that does all of that...)

This is a problem in practice for us.

We're trying to replace the C version of Cockpit with a Python zipapp, and the file gets created with permissions that allow the current user to run it, but won't allow the file to be installed in /usr/bin so everyone can run it.

We can work around it easy enough — chmod +x in the Makefile after we call zipapp, but this is a bug in zipapp that really ought to be fixed.

For what it's worth, I think the os.fdopen() approach originally proposed by "dholth" is the best one.

Linked PRs
  • gh-151970

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.