Protobuf: Restrictive permissions in release tarball

Created on 26 Aug 2015  路  9Comments  路  Source: protocolbuffers/protobuf

The release tarball in Pypy has very restrictive permissions in /protobuf-3.0.0a3/protobuf.egg-info/*.

All files are have 640 permission, but it should be 644.

Would be great if you could please fix this in the next release.

Thank you very much.

bug packaging & distribution python

Most helpful comment

@haberman this is still an issue with 3.0.0b2.post2. Any chance for a fix?

All 9 comments

@haberman

@StuntsPT does that mean users from a different group can not use the installed Proto Python package?

I can do

import google.protobuf

even with the current permissions, however, some other programs that rely on protobuf are crashing with:

PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/site-packages/protobuf-3.0.0a3-py3.4.egg-info/requires.txt'

"chmodding" this file to 644 will trigger a similar error:

PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/site-packages/protobuf-3.0.0a3-py3.4.egg-info/namespace_packages.txt'

Until all files in the .egg-info dir are in 644 mode.

Also, default user and group in a system-wide install are root:root (which makes sense to me, since it's on a system-wide install).

@StuntsPT does that mean users from a different group can not use the installed Proto Python package?

Yes, it does. Anyone not in the files' group (root by default) will be unable to access the contents of the files ("read" them), thus Python won't be able to evaluate the code and run it.

@haberman this is still an issue with 3.0.0b2.post2. Any chance for a fix?

It seems the uploaded release package mirrors the permission settings on our local machine. The same happens for ruby: https://github.com/google/protobuf/issues/1827

Still an issue in 3.0.0b4

Still an issue in 3.0.0 and this has been open for a year now.

Sorry guys, currently the release process is manual work and the release package's permission mirrors the release engineer's default permission settings for his/her file system. This cannot be fixed until we have an automatic release build pipeline. That's on our plan, though we don't have a timetable for it yet.

Was this page helpful?
0 / 5 - 0 ratings