Bug #7991

[Deployment] Debian package "python-google-api-python-client" egg info should be world-readable

Added by Chen Chen almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Brett Smith
Category:
Deployment
Target version:
Start date:
12/11/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
0.5

Description

The package render the pip of non-privileged users. "pip list", "pip install xxx" works, but "pip list --outdated" and "pip freeze" broke.
Install python-client directly from pip works for me.

There is already a "python-googleapi" package in Jessie official repo (https://packages.debian.org/jessie/python-googleapi), but it is a bit outdated (v1.2). I'm not sure if it meets the prerequisite of Arvados.

chenchen@shell:~$ pip freeze
Exception:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main
status = self.run(options, args)
File "/usr/lib/python2.7/dist-packages/pip/commands/freeze.py", line 66, in run
dependency_links.extend(dist.get_metadata_lines('dependency_links.txt'))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1413, in get_metadata_lines
return yield_lines(self.get_metadata(name))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1405, in get_metadata
return self._get(self._fn(self.egg_info, name))
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1514, in _get
with open(path, 'rb') as stream:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/google_api_python_client-1.4.2.egg-info/dependency_links.txt'

root@shell:~# apt-cache policy python-arvados-python-client
python-arvados-python-client:
Installed: 0.1.20151210204624-1
root@shell:~# apt-cache policy python-google-api-python-client
python-google-api-python-client:
Installed: 1.4.2-1


Subtasks

Task #8136: Review arvados-dev branch 7991-google-api-python-client-perms-wipResolvedBrett Smith

Associated revisions

Revision d42d4368
Added by Brett Smith almost 5 years ago

Merge branch '7991-google-api-python-client-perms-wip'

Closes #7991, #8136.

Revision d42d4368
Added by Brett Smith almost 5 years ago

Merge branch '7991-google-api-python-client-perms-wip'

Closes #7991, #8136.

Revision 5560d70b (diff)
Added by Brett Smith almost 5 years ago

7991: Update error message for pip build errors.

Refs #7991.

Revision 5560d70b (diff)
Added by Brett Smith almost 5 years ago

7991: Update error message for pip build errors.

Refs #7991.

Revision 886c3c5c (diff)
Added by Brett Smith almost 5 years ago

7991: pip build process detects if --no-use-wheel is supported.

Refs #7991.

Revision 886c3c5c (diff)
Added by Brett Smith almost 5 years ago

7991: pip build process detects if --no-use-wheel is supported.

Refs #7991.

History

#1 Updated by Brett Smith almost 5 years ago

  • Subject changed from Debain package "python-google-api-python-client" broke pip of non-privileged users to [Deployment] Debian package "python-google-api-python-client" egg info should be world-readable

Confirmed that google-api-python-client is the only backport with this issue, thankfully. We could just extend the fix that we've applied to httplib2, and apply it to this package as well.

#2 Updated by Brett Smith almost 5 years ago

  • Target version set to Arvados Future Sprints

#3 Updated by Brett Smith almost 5 years ago

  • Story points set to 0.5

#4 Updated by Brett Smith almost 5 years ago

  • Target version changed from Arvados Future Sprints to 2016-01-20 Sprint

#5 Updated by Brett Smith almost 5 years ago

  • Assigned To set to Brett Smith

#6 Updated by Brett Smith almost 5 years ago

  • Status changed from New to In Progress

#7 Updated by Brett Smith almost 5 years ago

A branch with a bugfix for the build is up for review. I built the package, installed it, confirmed the permissions were right, and confirmed that su -c 'pip freeze' nobody produced correct output after installation.

#8 Updated by Tom Clegg almost 5 years ago

LGTM.

Closest thing to a complaint is that we aren't fixing what looks to me like an existing bug here:

pyfpm_workdir=$(mktemp ...) && (
  set -e
  ...
)
if [ -n "$pyfpm_workdir" ]; then
  rm -rf "$pyfpm_workdir" 
fi

Shouldn't this be:

set -e
pyfpm_workdir=$(mktemp ...)
...
rm -rf "$pyfpm_workdir" 

If we fail to make a tmpdir, we should probably admit defeat, rather than silently building a package with broken permissions...

#9 Updated by Brett Smith almost 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados-dev|commit:d42d4368192ec140faf161db6c98a500aa39fdcd.

#10 Updated by Brett Smith almost 5 years ago

Tom Clegg wrote:

Closest thing to a complaint is that we aren't fixing what looks to me like an existing bug here:

I know this code is subtle, but I don't think that's right. I think the current code does what you want; and I think it's better than your suggestion. We want to clean the tmpdir, whether the build process succeeds or fails, at any point. The cleanest way to do that from a code perspective is to do that cleanup after the subshell doing the main build is done. If we do that, we can't do the mktemp inside the subshell, because we'll forget where the tmpdir is after the subshell is done.

Chaining the mktemp and the subshell with && means that the build is prevented if making a temporary directory fails. In that case, the subshell doesn't run at all, and $? will have mktemp's exit code when we check that later, so there's an error about it.

Did I understand you right, or did I miss something in your comment?

#11 Updated by Tom Clegg almost 5 years ago

No, you're right. Apparently I ignored the if [ 0 != "$?" ] part. Sorry for the noise.

Also available in: Atom PDF