Re: fsync-pgdata-on-recovery tries to write to more files than previously

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: fsync-pgdata-on-recovery tries to write to more files than previously
Дата
Msg-id 20150529182836.GC26667@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: RFC: Remove contrib entirely
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Need Force flag for pg_drop_replication_slot()