Permissions issue detected on the tarballs/base file during upgrade to MacPorts 2.8.0

[Olaf Sulla]

Thank you Ryan,

I can confirm that the port command will run without error with the new version of MacPorts base after the initial error report.

Regarding the default UID and GID:

-	The GID, as you mention, already exists on the system via virtue of a previous install of postgreSQL packages.

-	The UID 500 does not pre-exist.

The latter might be the problem because the parent folder has the permissions of root:wheel. With there being no account with the UID of 500 existing on the system, it is not listed in wheel and so this may cause sudo to fail.


> On 20 Oct 2022, at 19:41, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Oct 20, 2022, at 10:11, Olaf Sulla wrote:
> 
>> I installed the update to MacPorts 2.8.0 earlier today on a Mac Mini A1 running Monterey 12.6.
>> 
>> During the install the following error was reported:
>> 
>> NFO: Syncing port data and updating port-base ...
>> Password:
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 2.7.2 installed,
>> MacPorts base version 2.8.0 downloaded.
>> --->  Updating the ports tree
>> --->  MacPorts base is outdated, installing new version 2.8.0
>> Installing new MacPorts release in /opt/local as root:wheel; permissions 0755
>> 
>> Error: Couldn't change permissions of the MacPorts sources at /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base to root: child killed: kill signal
>> Please run `port -v selfupdate' for details.
>> Error: /opt/local/bin/port: port selfupdate failed: Couldn't change permissions of the MacPorts sources at /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base to root: child killed: kill signal
>> ERROR: Self update failed with exit code: 1
>> ERROR: MacPorts sync failed
>> 
>> I re-ran the self update with the ‘-v’ option but no error was reported.
> 
> We also saw these errors on our automated build system, e.g.:
> 
> https://build.macports.org/builders/ports-11_x86_64-watcher/builds/24366/steps/selfupdate/logs/stdio
> 
> And other users have reported the error too:
> 
> https://trac.macports.org/ticket/66031
> 
> So there does appear to be some problem that we need to fix.
> 
> After our automated build system encountered this error, MacPorts 2.8.0 was nevertheless installed and appeared to work normally, so you may be able to just ignore the error for now.
> 
> 
>> I checked the folder permissions:
>> 
>> ls -la /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs  
>> total 226484
>> drwxr-xr-x 10 root wheel          320 Oct 20 11:50 .
>> drwxr-xr-x  3 root wheel           96 Nov 29  2020 ..
>> -rw-r--r--  1 root wheel     18098189 Oct 20 08:34 PortIndex
>> -rw-r--r--  1 root wheel          512 Oct 20 08:56 PortIndex.rmd160
>> drwxr-xr-x 30 root postgres       960 Oct 20 07:02 base
>> -rw-r--r--  1 root wheel    113716224 Oct 20 07:45 base.tar
>> -rw-r--r--  1 root wheel          512 Oct 20 07:45 base.tar.rmd160
>> drwxr-xr-x 62 root postgres      1984 Oct 20 11:50 ports
>> -rw-r--r--  1 root wheel    100087808 Oct 20 08:56 ports.tar
>> -rw-r--r--  1 root wheel          512 Oct 20 08:56 ports.tar.rmd160
>> 
>> Group II:
>> 
>> drwxr-xr-x 30 0 505       960 Oct 20 07:02 base
>> drwxr-xr-x 62 0 505      1984 Oct 20 11:50 ports
>> 
>> 
>> The ‘postgres’ group is listed via dscl.
>> 
>> I was not expecting to see the group set to ‘postgres’ on these folders. 
>> 
>> Could you please advise if I should raise one or more tickets for this, and could you confirm what permissions I should expect to find on these folders.
> 
> The files in the base.tar and ports.tar tarballs generated by our server are currently owned by uid 500 and gid 505 because those are the uid and gid of the process that runs on the server that generates the tarballs. What those uid and gid map to on each user's system will be different, so you may see different usernames and group names for those files on each system, or you may see the numbers 500 or 505 if you do not have those uids or gids assigned. On your system, gid 505 happens to have been assigned to postgres. This situation is untidy, but has not been a problem before. Ideally, to reduce confusion, I should change the server-side process that generates the tarballs so that the files are owned by a predictable user and group, such as the macports user and group, but I haven't done that yet. This will require either running the process as the macports user (which is untidy and may be impossible due to the deliberately limited capabilities of that user), running the process as root (which I had hoped to avoid because it gives that process unlimited capabilities), or using the fakeroot program (which I think will work).
>