Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jHxA8-0008K1-U4 for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2020 22:09:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jHxA7-0006GT-NN for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2020 22:09:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jHxA7-0006FM-B8 for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2020 22:09:11 +0000 Received: from tamriel.snowman.net ([96.255.250.162]) by makus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jHxA4-0001pP-0z for pgsql-hackers@postgresql.org; Fri, 27 Mar 2020 22:09:09 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id BB6045F798; Fri, 27 Mar 2020 18:09:10 -0400 (EDT) Date: Fri, 27 Mar 2020 18:09:10 -0400 From: Stephen Frost To: Andres Freund Cc: Robert Haas , Amit Kapila , Suraj Kharage , tushar , Rajkumar Raghuwanshi , Rushabh Lathia , Tels , David Steele , Andrew Dunstan , PostgreSQL Hackers , Jeevan Chalke , vignesh C Subject: Re: backup manifests Message-ID: <20200327220910.GN13712@tamriel.snowman.net> References: <20200327062927.2ijbvoa7pqoc3w7b@alap3.anarazel.de> <20200327203225.hcm6ag4grwsiruea@alap3.anarazel.de> <20200327214407.GL13712@tamriel.snowman.net> <20200327215603.2u67mu4okek2uqvh@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E0e4ihfNxLmjeTLW" Content-Disposition: inline In-Reply-To: <20200327215603.2u67mu4okek2uqvh@alap3.anarazel.de> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --E0e4ihfNxLmjeTLW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, * Andres Freund (andres@anarazel.de) wrote: > On 2020-03-27 17:44:07 -0400, Stephen Frost wrote: > > * Andres Freund (andres@anarazel.de) wrote: > > > On 2020-03-27 15:20:27 -0400, Robert Haas wrote: > > > > On Fri, Mar 27, 2020 at 2:29 AM Andres Freund = wrote: > > > > > Hm. Should this warn if the directory's permissions are set too o= penly > > > > > (world writable?)? > > > >=20 > > > > I don't think so, but it's pretty clear that different people have > > > > different ideas about what the scope of this tool ought to be, even= in > > > > this first version. > > >=20 > > > Yea. I don't have a strong opinion on this specific issue. I was most= ly > > > wondering because I've repeatedly seen people restore backups with wo= rld > > > readable properties, and with that it's obviously possible for somebo= dy > > > else to change the contents after the checksum was computed. > >=20 > > For my 2c, at least, I don't think we need to check the directory > > permissions, but I wouldn't object to including a warning if they're set > > such that PG won't start. I suppose +0 for "warn if they are such that > > PG won't start". >=20 > I was thinking of that check not being just at the top-level, but in > subdirectories too. It's easy to screw up the top and subdirectory > permissions in different ways, e.g. when manually creating the database > dir and then restoring a data directory directly into that. IIRC > postmaster doesn't check that at start. Yeah, I'm pretty sure we don't check that at postmaster start.. which also means that we'll start up just fine even if the perms on subdirectories are odd or wrong, unless maybe we end up in a really odd state where a directory is 000'd or something. Of course.. this is all a mess when it comes to pg_basebackup, really, as previously discussed elsewhere, because what permissions and such you end up with actually depends on what *format* you use with pg_basebackup- it's different between 'tar' format and 'plain' format. That is, if you use 'tar' format, and then actually use 'tar' to extract, you get one set of privs, but if you use 'plain', you get something different. I mean.. pgBackRest sets all perms to whatever is in the manifest on restore (or delta), but this patch doesn't include the permissions on files, or ownership (something pgBackRest also tries to set, if possible, on restore), does it...? Doesn't look like it on a quick look. So if we want to compare to pgBackRest then, yes, we should include the permissions in the manifest and we should check that everything in the manifest matches what's on the filesystem. I don't think we should just compare all permissions or ownership with some arbitrary idea of what we think they should be, even though if you use pg_basebackup in 'plain' format, you actually end up with differences, today, from what the source system has. In my view, that should actually be fixed, to the extent possible. Thanks, Stephen --E0e4ihfNxLmjeTLW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJefnmGAAoJEO1sijiDR2RVOkQQAIZH8Ia29n1hiPcnR/Ew1muO R/pPMQ8UKRNL9S34A/xoUmAxI3i24rSK7mFkJg2aMFUw6Tp25MqRZ7blQGP7YdCU qAVYNDcOJ9II111DS0h26Qy9kx70wm8M5D0SegFUjfZFNvAWYkq0J8IItW1pTZCU lmbbrY4q3Iq7FjUMarxTjbBZ43W9ZMJLfxqTYajg9QMJ40960vUa+UErjHajdf4T yRM0y3pYAjHe2rhGNuKHr49LM4QmYZLNPiZGjQ1B8/sna6TlT7W46jp6AHwNhs64 7O+9kiPikldrC13tmpa2q3caDdZV9JGDTlbVVr0/SJxQ2XD/si2aR+wCpzt5yGDc OjVCXNlapqn5S/3PyKcaC4ApzyLhrIptXvbUbOieo2+3pXJou2lhRdj0d6wbRqG8 cpYT0i1MbkapHct38h6WE5gyg6moUP86e362RmIBQgzfhImYIDBSHpRh+KLoVE9p pvkNRYRWy/59UiXASX6LYnaL2k8naIhzHEJ7iy44YCG2HNXJOcts3uvRGU4PbBP4 kYH957K6Kpc/xz+0KA1E0W6VWg6m0Lc3/kM1zyH5zOrHL/48BjI7P5sf+HBAcNOr FWpRkZKDGf21KWzNUd0D2EcqDfaYKBQ5nzSBADAfoRs5+on3VOP+xP6IF0KVXUMl 2PYXG6A2JlpydAjiWO// =Ln95 -----END PGP SIGNATURE----- --E0e4ihfNxLmjeTLW--