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

file permissions issue #30

Closed
0-wiz-0 opened this issue May 22, 2016 · 10 comments
Closed

file permissions issue #30

0-wiz-0 opened this issue May 22, 2016 · 10 comments

Comments

@0-wiz-0
Copy link

0-wiz-0 commented May 22, 2016

With the 2.3 tarball from pypi, the file permissions of the files in site-packages/libarchive_c-2.3-py3.5.egg-info/* are incorrect (600), which breaks installation of packages which want to use this but are not run by root.
I'm not sure where these permissions come from.
It was the same with 2.2.

@Changaco
Copy link
Owner

I'm the one who created the package, and my umask is 066, so that's where the 600 permissions come from. The question is: what's the best way to fix your problem?

@0-wiz-0
Copy link
Author

0-wiz-0 commented May 25, 2016

I don't know the exact process how you create these, but I hope you call a script or python setup target. Can you add a umask call somewhere there?

@Changaco
Copy link
Owner

Good idea, an os.umask(2) call in setup.py might do the trick.

@Changaco
Copy link
Owner

Changing the umask isn't enough, we need to change the permissions of all source files in the git repo because setuptools uses hard links when it creates tarballs.

@Changaco
Copy link
Owner

To clarify, permissions are fine in git, they're just wrong in my local copy.

@Changaco
Copy link
Owner

2.4 release with correct permissions uploaded to PyPI.

@anthraxx
Copy link

hm this umask changes resulted in python setup.py install creating the /usr/lib/python2.7/site-packages/ directory with permissions 775 instead of 755 making in group writable. This is not really optimal for distribution level of packaging as the directory permissions differ from the global expected values.
in my opinion having that umask in the setup.py is not really optimal and i needed to patch it away to create packages for the distribution that can be shipped

@0-wiz-0
Copy link
Author

0-wiz-0 commented May 31, 2016

Why not use the proper umask (octal 022) instead, then?

@Changaco
Copy link
Owner

sigh, you're right I should have used 022, matching the u=rwX,g=rX,o=rX I put in the Makefile. I don't think it's worth another release though.

@anthraxx
Copy link

well, fair enough... it think that will work 😸
No, I assume most package maintainers that care will notice that themselves, from my point of view its perfectly fine if it only gets into the next release! Thank you very much for fixing my concern!
have a nice day 👍

Changaco added a commit to Changaco/python-etherpad_lite that referenced this issue Jun 1, 2016
Changaco added a commit that referenced this issue Nov 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants