mksetupini aborts if run by a normal user

[Jon Turney]

On 13/04/2025 08:02, Brian Inglis via Cygwin wrote:
> On 2025-04-12 08:59, ggl329 via Cygwin wrote:
>> Hi Jon,
>>
>> Thanks for updating calm package.
>>
>> Usually, I work as a normal user. (i.e., not as root or an administrator)
>> In this case, mksetupini aborts with a permission error.
>> It is because Python library files do not have permission to normal 
>> users.

Oh! That's not right.

Thanks very much for reporting this.

>> Could you modify the file permissions so that they are accessible to 
>> non- privileged users?

I've rebuilt the package as calm-20250329-2, which I think has the 
correct permissions.

>> $ cygcheck -dc | grep calm
>> calm                                    20250329-1
>>
>> $ mksetupini
>> Traceback (most recent call last):
>>    File "/usr/bin/mksetupini", line 5, in <module>
>>      from calm.mksetupini import main
>>    File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
>>    File "<frozen importlib._bootstrap>", line 986, in 
>> _find_and_load_unlocked
>>    File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
>>    File "<frozen importlib._bootstrap_external>", line 846, in 
>> exec_module
>>    File "<frozen importlib._bootstrap_external>", line 982, in get_code
>>    File "<frozen importlib._bootstrap_external>", line 1039, in get_data
>> PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.9/ 
>> site- packages/calm/__init__.py'
>>
>> $ ls -ld /usr/lib/python3.9/site-packages/calm
>> drwxrwx--- 1 root Administrators 0 Apr 12 23:23 /usr/lib/python3.9/ 
>> site- packages/calm
>>
>> $ ls -ld /usr/share/doc/calm
>> drwxrwx--- 1 root Administrators 0 Apr 12 23:23 /usr/share/doc/calm
> 
> Previously installed python packages all have a+r files and a+rx dirs, 
> with .py one or the other, including the previous calm tars, whereas the 
> latest release file perms in the tar are not all consistent with each 
> other or previous releases, also for the .../calm...dist-info dir and 
> files!

Yeah, this seems to be due to an interaction between a change in the way 
permissions are mapped onto ACLs in 3.6.0, and the slightly weird 
inheritable ACL setup in the VM used to build packages.

I don't think there's anything python specific in this, so I suspect 
this might have effected a few other packages which were built using 
3.6.0 (which isn't the case currently due to some stability concerns).