- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Packages
-
Assigned To
Andreas Baumann - Operating System i486
- Severity Low
- Priority Very Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by Peter Tirsek - 09.01.2021
Last edited by Andreas Baumann - 16.01.2021
FS#122 - Permissions bits on files on the primary mirror are too restrictive
In my quest to find a working mirror close to me, I’ve come across another issue with at least a couple of mirrors. Some mirrors respond with a HTTP 403 Forbidden for certain files, notably many of the Pacman database files. At the time of this writing, I’m aware of this problem happening with the princeton.edu and the clarkson.edu mirrors. I’ve been in contact with the admin of one of the mirrors, and they’ve pointed out that the permission bits are set to 0600 at the source. If the primary mirror could have their files be world readable, it would likely fix this problem automatically across more than one mirror.
Is that something we can do?
Steps to verify:
1. Access certain files from the primary mirror using rsync, for example:
% rsync -av rsync://mirror.archlinux32.org/archlinux32/i686/extra/extra.db.tar.gz . receiving incremental file list extra.db.tar.gz sent 43 bytes received 2,044,453 bytes 371,726.55 bytes/sec total size is 2,043,851 speedup is 1.00
2. Examine permission bits:
% ls -l extra.db.tar.gz -rw------- 1 user user 2043851 Jan 8 11:51 extra.db.tar.gz
Should be -rw-r–r–.
16.01.2021 12:42
Reason for closing: Fixed
Additional comments about closing:
Ok, I implemented a crude hack
(fixmirrorperms.service and
/usr/local/bin/fixmirrorperms) using
inotify to fix the mirror
ownerships and permission.
I pulled a complete file list using rsync's –list-only flag, and it looks like all files published to the mirror since some time on December 27, except for IRC logs, have their permission bits set this way. What happened on December 27? :)
I'm actually not quite sure what happened, but it seems rsync is just working
in a different way than before. After rsyncing from the mirror I started to
just chmod/chown the files on my own mirror.
I hope you're not saying that the solution to this is that the individual mirrors should chmod the files after rsync'ing. One of the mirror admin I've been in contact with expressed that they would have a hard time doing that; even changing settings to force a –chmod parameter on the rsync command line would be difficult, because their setup uses templates, to make being a mirror for a large number of projects easier.
Surely the problem exists in whatever pushes the finished packages and pacman dbs to the primary mirror, and can be addressed there to fix the problem once and for all?
We have now a bindfs mount in place which makes sure that mirror sees the files as 'mirror'
(for rsync) and the webserver as user 'http'. This should solve the problem, we think.
It sounds like you're influencing the owner of the files. It's my impression that the problem is the permission bits, that files are presented to the remote rsync as mode 600 instead of 644. Presumably the easiest fix to that would be to chmod them on the primary mirror (and to ensure that new files are uploaded with mode 644 as well), or am I missing something in how this works?
Yep, the bindfs is basically a workaround, so that the files get rsynched at all.
I tried several thigngs (setting chmod in rsync on build slaves), trying to force
the umask on the server rsyncd, but nothing had any positive effects.
The last idea I have is to add a inotifyd and change the file permissions on
the fly..