From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
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 01:55:30 |
Message-ID: | 20200207015530.GP23913@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Thu, Feb 06, 2020 at 09:44:07AM -0500, Stephen Frost wrote:
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> On Thu, Feb 6, 2020 at 8:04 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>>> You have a point with -Ft as untaring the tarballs from a base backup
>>> taken with pg_basebackup -Ft used by root generates files owned by the
>>> original user. -Fp enforces the files to be owned by the user taking
>>> the backup, which makes the most sense, so for consistency with the
>>> other tools preventing root to run pg_basebackup makes sense to me
>>> with -Fp. Any thoughts from others to restrict the tool with -Fp but
>>> not with -Ft? The argument of consistency mattered for me first for
>>> both formats.
>
> 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. 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?
>> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-02-07 02:07:02 | Re: pgsql: Prevent running pg_basebackup as root |
Previous Message | Michael Paquier | 2020-02-07 01:54:07 | pgsql: Revert "Prevent running pg_basebackup as root" |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-02-07 02:07:02 | Re: pgsql: Prevent running pg_basebackup as root |
Previous Message | Amit Langote | 2020-02-07 01:39:52 | Re: table partitioning and access privileges |