Re: fsync-pgdata-on-recovery tries to write to more files than previously - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date
Msg-id 20150529182836.GC26667@tamriel.snowman.net
Whole thread Raw
In response to Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
* Andres Freund (andres@anarazel.de) wrote:
> On 2015-05-29 13:49:16 -0400, Tom Lane wrote:
> > > That sounds like a potentially nontrivial amount of repetitive log bleat
> > > after every crash start? One which the user can't really stop?
> >
> > Why can't the user stop it?
>
> Because it makes a good amount of sense to have e.g. certificates not
> owned by postgres and not writeable? You don't necessarily want to
> symlink them somewhere else, because that makes moving clusters around
> harder than when they're self contained.

A certain other file might be non-writable by PG too... (*cough* .auto
*cough*).

> > I'd say it's a pretty damn-fool arrangement: for starters, it's an
> > unnecessary security hazard.
>
> I don't buy the security argument at all. You likely have
> postgresql.conf in the data directoy. You can write to at least .auto,
> which will definitely reside the data directory. That contains
> archive_command.

I'm not sure that I see the security issue here either..  We're not
talking about setuid shell scripts or anything that isn't running as the
PG user, which a superuser could take over anyway..
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: RFC: Remove contrib entirely
Next
From: Stephen Frost
Date:
Subject: Re: Need Force flag for pg_drop_replication_slot()