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 по дате отправления: