PermissionError: [Errno 13] Permission denied: 'skyfield-1.16-py3.8.egg/skyfield/data/nutation.npz'

[Deuchnord]

On a fresh install of the Skyfield library, the import the timelib module fails with the following stack trace:

Traceback (most recent call last):
  File "/usr/bin/kosmorro", line 24, in <module>
    from kosmorrolib import dumper
  File "/usr/lib/python3.8/site-packages/kosmorrolib/dumper.py", line 23, in <module>
    from skyfield.timelib import Time
  File "/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/timelib.py", line 10, in <module>
    from .nutationlib import compute_nutation, earth_tilt, iau2000a
  File "/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/nutationlib.py", line 6, in <module>
    _arrays = load_bundled_npy('nutation.npz')
  File "/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/functions.py", line 124, in load_bundled_npy
    data = get_data('skyfield', 'data/{0}'.format(filename))
  File "/usr/lib/python3.8/pkgutil.py", line 637, in get_data
    return loader.get_data(resource_name)
  File "<frozen importlib._bootstrap_external>", line 972, in get_data
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data/nutation.npz'

I checked the files in the /usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data/nutation.npz and found out that most of them (but not all) are missing the read permission, making it impossible to read them unless running as root:

$ ls -l /usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data
total 84
drwxr-xr-x 1 root root   434 12 janv. 09:57 .
drwxr-xr-x 1 root root   830 12 janv. 09:57 ..
-rw-r----- 1 root root  3595 12 janv. 09:57 constellations.npz
-rw-r----- 1 root root 11697 12 janv. 09:57 deltat.data
-rw-r----- 1 root root  2237 12 janv. 09:57 deltat.preds
-rw-r--r-- 1 root root  1354 12 janv. 09:57 earth_orientation.py
-rw-r--r-- 1 root root  2453 12 janv. 09:57 gravitational_parameters.py
-rw-r--r-- 1 root root  2798 12 janv. 09:57 hipparcos.py
-rw-r----- 1 root root 10576 12 janv. 09:57 historic_deltat.npy
-rw-r--r-- 1 root root   706 12 janv. 09:57 horizons.py
-rw-r--r-- 1 root root    72 12 janv. 09:57 __init__.py
-rw-r----- 1 root root  1352 12 janv. 09:57 Leap_Second.dat
-rw-r----- 1 root root   528 12 janv. 09:57 morrison_stephenson_deltat.npy
-rw-r----- 1 root root 15728 12 janv. 09:57 nutation.npz
drwxr-xr-x 1 root root   322 12 janv. 09:57 __pycache__
-rw-r--r-- 1 root root  4682 12 janv. 09:57 spice.py

As a temporary fix, the missing permission to the others group can be added:

$ sudo chmod o+r /usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data/*

Running Python 3.8.1 on Arch Linux. The same issue happens whenever I install Skyfield through PyPI or the AUR.

[brandon-rhodes]

I generally use virtualenv to install packages, so I'm not familiar with everything that can go wrong when installing system-wide as root — was pip the tool you used? If so, how did you invoke it? For the root user, what is the output of umask? If you have the root account's umask set to something like 027, then I have seen permission bits missing on installed files and binaries.

[Deuchnord]

was pip the tool you used?

Yes, I'm using pip version 19.3.

If so, how did you invoke it?

Since it's a dependency of my program, Skyfield is installed when I invoke this:

$ sudo pip install kosmorro

which makes it install Skyfield, just like I ran sudo pip install skyfield.

Trying to install it user-wide instead (without sudo and with the --user argument) seems to work, though.

For the root user, what is the output of umask?

# umask
0022

[brandon-rhodes]

Thanks for the additional info. If you look at the other packages installed, do you find data files that normal users cannot read? Or was Skyfield the only package that had some files unreadable?

[Deuchnord]

I'm actually wondering if there's actually any sense to install a software/library on a system but not having access to its files as a regular user? I mean, the only situation when this happens is usually for security purpose, like storing SSH/GPG private keys… if a file does not contain anything that should be only accessible to someone having the super-administrator access to the system, I don't see any reason for it being inaccessible to regular users 😕

[brandon-rhodes]

Welp. It's a bug in distutils!

https://github.com/kjd/idna/issues/66#issuecomment-398007302

Apparently the fact that I don't have public permissions set on my personal computer (because I use the same dotfiles on Linux machines that have other users besides me) means that everyone installing the wheel gets my private permission decisions imposed on them.

I wonder how I can fix this systematically, for all the Python packages I distribute? I assume that, for example, jplephem also — oh, but maybe it for some reason only happens to data files? Anyway, I'll probably switch to a more generous umask but then have a way to keep my home directory with a permission of o-x so that no one can get it to my files to begin with.

Feels fragile, but otherwise I'd somehow have to either hijack every setup.py file I run to change the umask, or else remember to always run a special script before doing distributions. I suspect that would be more prone to error.

Let's leave this open until I release Skyfield again (hopefully later this week), at which point we can verify whether the permissions issues are fixed.

[Deuchnord]

Quite weird, but the issue completely disappeared on my computer tonight, so everything seems to work again without any other action than reinstalling Skyfield.

Computer science :man_shrugging:

[brandon-rhodes]

I'm glad it's working again! I'm going to close this for now, but feel free to re-open if the problem reappears, or if you notice what made the difference between a working and not-working installation.