Re: Lockfile restart failure is still there :-(

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Lockfile restart failure is still there :-(
Дата
Msg-id 873butki1p.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Lockfile restart failure is still there :-(  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Lockfile restart failure is still there :-(  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> I am strongly tempted to add a direct check in checkDataDir() that the
> data directory actually does belong to our own uid, just for paranoia's
> sake.  Someone might decide that they could relax the permission check
> ("hey, why not let the dbadmin group have write permission on $PGDATA")
> without realizing they'd be weakening the startup safety interlock.

Personally I often find I want to do exactly the kind of thing you're
describing. Why does the whole directory have to be so restrictive? Why not
just verify that the lock file itself is owned by our userid? Someone could
always chown it of course but short of that if it's owned by our userid then
surely the process that created it had to be our userid as well?

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: depended on table types
Следующее
От: Tom Lane
Дата:
Сообщение: Re: depended on table types