pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrew Dunstan <andrew@dunslane.net>
To: Noah Misch <noah@leadboat.com>
To: marco atzeri <marco.atzeri@gmail.com>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Skip some permissions checks on Cygwin
Date: Mon, 24 Jun 2024 16:58:33 -0400
Message-ID: <003457fd-cc74-4e6a-bc0e-2891d40d4621@dunslane.net> (raw)
In-Reply-To: <20240624204221.42.nmisch@google.com>
References: <E1sHjJc-001KCN-H6@gemulon.postgresql.org>
	<20240624010311.0b.nmisch@google.com>
	<fb2c5702-a51d-4d15-a523-83a0443f0df5@dunslane.net>
	<20240624204221.42.nmisch@google.com>


On 2024-06-24 Mo 4:42 PM, Noah Misch wrote:
> On Mon, Jun 24, 2024 at 10:17:32AM -0400, Andrew Dunstan wrote:
>> On 2024-06-23 Su 9:03 PM, Noah Misch wrote:
>>> On Thu, Jun 13, 2024 at 12:12:29PM +0000, Andrew Dunstan wrote:
>>>> Skip some permissions checks on Cygwin
>>>>
>>>> These are checks that are already skipped on other Windows systems.
>>>>    	skip "unix-style permissions not supported on Windows", 2
>>>> -	  if ($windows_os);
>>>> +	  if ($windows_os || $Config::Config{osname} eq 'cygwin');
>>>> -	skip "group access not supported on Windows", 3 if ($windows_os);
>>>> +	skip "group access not supported on Windows", 3
>>>> +	  if ($windows_os || $Config::Config{osname} eq 'cygwin');
>>> Cygwin does support Unix-style permissions, so I'm not following the rationale
>>> for this change.  Can you say more?
>> It seems to have some difficulties with group permissions in some cases. I
>> improved the error message a bit, and got a bunch that all look like this:
>>
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/global/6303
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/global/pg_control
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/global/pg_filenode.map
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5
>> mode must be 0750, not 0000000000000000000000000000000000000700
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5/112
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5/113
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5/1247
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5/1247_fsm
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5/1247_vm
>> mode must be 0640, not 0600
>> build/testrun/initdb/001_initdb/log/regress_log_001_initdb:*main::STDERR/home/Administrator/postgresql/build/testrun/initdb/001_initdb/data/tmp_test_qlhf/data_group/base/5/1249
>> mode must be 0640, not 0600
>>
>>
>> Apparently there's some issue with the group None. I don't mind digging
>> further if you think it might be worthwhile, but it seemed to me that since
> I'll guess digging further is not worthwhile.  Even if it is a PostgreSQL bug,
> the consequences seem limited to unintentionally withholding group access.
> There's a remote chance you're using a "noacl" mount, where this result could
> fit.


mount doesn't show noacl being used


>
>> we didn't mind too much skipping these checks on native Windows we wouldn't
>> mind on Cygwin either.
> The reasons for skipping the test are different on native Windows (does not
> provide POSIX file modes) vs. Cygwin (has POSIX file modes, but the
> combination of PostgreSQL and Cygwin somehow reaches the wrong mode).


True.


I wonder if Marco can shed any light on what's going on here.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com






view thread (12+ messages)  latest in thread

Message-ID: <003457fd-cc74-4e6a-bc0e-2891d40d4621@dunslane.net>
Permalink:  ../003457fd-cc74-4e6a-bc0e-2891d40d4621@dunslane.net/
Also on:    postgresql.org/message-id/003457fd-cc74-4e6a-bc0e-2891d40d4621@dunslane.net

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: andrew@dunslane.net, noah@leadboat.com, marco.atzeri@gmail.com, pgsql-committers@lists.postgresql.org
  Subject: Re: pgsql: Skip some permissions checks on Cygwin
  In-Reply-To: <003457fd-cc74-4e6a-bc0e-2891d40d4621@dunslane.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox