Re: Session Identifiers - Mailing list pgsql-general
| From | oleg yusim |
|---|---|
| Subject | Re: Session Identifiers |
| Date | |
| Msg-id | CAKd4e_FzXdntY-_MFtGDDMaEJQL84QzKVDpF_U8yeP7Dpsw6NA@mail.gmail.com Whole thread Raw |
| In response to | Re: Session Identifiers (Pavel Stehule <pavel.stehule@gmail.com>) |
| Responses |
Re: Session Identifiers
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| List | pgsql-general |
Got it, thanks... Now, is it any protection in place currently against replacing Session ID (my understanding, it is kept in memory, belonging to the session process) or against guessing Session ID (i.e. is Session ID generated using FIPS 140-2 compliant algorithms, or anything of that sort)?
Oleg
On Sun, Dec 20, 2015 at 11:02 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2015-12-20 17:52 GMT+01:00 oleg yusim <olegyusim@gmail.com>:Hi Pavel,Thanks, for your response, it helps. Now, from my observations (PostgreSQL 9.4.5, installed on Linux box), if I enter psql prompt at my ssh to the box session and leave it open like that, it doesn't time out. Is it really a case? Session to PostgreSQL DB doesn't terminate on timeout (or rather doesn't have one), or I just happened to miss configuration option?any unbound process started as custom session means critical error - and there are not any related known bug. Postgres hasn't any build option for terminating session. If you need it - the pgbouncer has one or you can terminate session via pg_terminate_backend and cron. Maybe somebody will write background worker for this purpose. Internally, the system processes and sessions has pretty strong relation in Postgres. - there cannot be process without session and session without process.PavelThanks,OlegOn Sun, Dec 20, 2015 at 10:08 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:Hi2015-12-20 16:16 GMT+01:00 oleg yusim <olegyusim@gmail.com>:Greetings!I'm new to PostgreSQL, working on it from the point of view of Cyber Security assessment. In regards to the here is my questions:From the security standpoint we have to assure that database invalidates session identifiers upon user logout or other session termination (timeout counts too).Does PostgreSQL perform this type of actions? If so, where are those Session IDs are stored, so I can verify it?Postgres is based on processes - for any session is created new process when user is logged and this process is destroyed when user does logout. Almost all data are in process memory only, but shared data related to sessions are stored in shared memory - in array of PGPROC structures. Postgres invalidates these data immediately when process is destroyed. Search PGPROC in our code. Look to postmaster.c, where these operations are described.What I know, there are not any other session data - so when process is destroyed, then all is destroyed by o.s.Can be totally different if you use some connection pooler like pgpool or pgbouncer - these applications can reuse Postgres server sessions for more user sessions.RegardsPavelThanks,Oleg
pgsql-general by date: