Re: Row-level Security vs Application-level authz

Поиск
Список
Период
Сортировка
От Karsten Hilbert
Тема Re: Row-level Security vs Application-level authz
Дата
Msg-id trinity-8982fe10-bda6-4ea2-83e4-e24c8ab1c7e3-1424846721547@3capp-gmx-bs51
обсуждение исходный текст
Ответ на Re: Row-level Security vs Application-level authz  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-general
> * David Steele (david@pgmasters.net) wrote:
> > So I guess my last question is if you are inserting rows into a table to
> > track user connections, how do you clean them out when the client does
> > not disconnect cleanly?  Or is this table intended to be append-only?
>
> It wouldn't be intended to be append-only but I agree that, ideally,
> there'd be a way to address clients disconnect uncleanly.  One way to
> address that would be by having the security definer function that's
> called on entry check to see if there was a prior session for its pid
> and log an error when found.  With a connection pooler, that'd probably
> turn up any issues pretty quickly as the set of pids would be relatively
> small (compared to the overall potential pid space).  Another approach
> would be to have it check for all backends by joining against
> pg_stat_activity, but that might result in false positives.  A cron job
> could also be used to check for sessions beyond a certain expected
> lifetime (PHP and other systems do this at the filesystem level; it's
> not ideal but it does seem to work).

One could use an exclusive lock. When the client goes away
so does the lock.

If the security definer func can get the lock on an existing
entry the entry is bogus.

Karsten


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

Предыдущее
От: David G Johnston
Дата:
Сообщение: Re: 9.3: bug related to json
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: (unknown)