Re: pgsql: Prevent running pg_basebackup as root

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Prevent running pg_basebackup as root
Date: 2020-02-07 19:22:09
Message-ID: 20200207192208.GL3195@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Greetings,

* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> On Thu, Feb 06, 2020 at 09:44:07AM -0500, Stephen Frost wrote:
> > Erm- no, with -Ft + untar-as-root they get owned by "postgres", NOT the
> > original user. That's what I was pointing out up-thread (since it seems
> > to be confusing- and clearly not always well understood..) and it's an
> > issue imv, but it's independent of this, so probably deserves its own
> > thread if someone wants to do something about that.
>
> Hmm. I don't think that you are completely correct here either as it
> depends on if the OS user "postgres" exists or not.

Yes, I do know what happens if the named user doesn't exist, but in the
general case, where the 'postgres' user does exist, they'll get owned by
'postgres'.

> As mentioned in
> https://www.gnu.org/software/tar/manual/tar.html#SEC138, if the user
> name cannot be found in /etc/passwd, then tar switches to the user ID
> (if one does not have any user or group named "postgres", then the
> files are untar'ed with the same user and group as the one running the
> cluster and that's to the UID and GID set by tarCreateHeader, as you
> say). I think that it is a problem to not have more documentation on
> the matter (now there is just a small mention in the base backup
> restore about being sure to have the proper permissions). And it may
> be interesting to add into pg_basebackup options to enforce the user
> and/or group similarly to what tar does with --owner and --group?

Yes, I agree with improving the documentation and with adding such
options.

> >> I agree with Stephen that this seems to be misguided, and my vote is
> >> to revert. I would've also objected had you given more than 2 days
> >> warning before committing, and it happened to be during FOSDEM. I saw
> >> the original email which clearly said it'd be in the March commitfest,
> >> so I figured I'd have time...
> >
> > Yeah, I also agree with reverting this change. Even if we can come to
> > something we all agree on, I'm pretty confident it's not going to be
> > exactly this patch, so let's back it out for now and discuss it further
> > on the -hackers thread.
>
> OK, done that part as of dcddc3f.

Great, thanks!

Stephen

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-02-07 19:25:27 Re: pgsql: Fix bug in Tid scan.
Previous Message Tom Lane 2020-02-07 18:06:46 Re: pgsql: Fix page modification outside of critical section in GIN

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-02-07 19:34:34 Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Previous Message Tomas Vondra 2020-02-07 19:02:01 Re: logical decoding : exceeded maxAllocatedDescs for .spill files