Re: [HACKERS] semaphore usage "port based"?


On Mon, 3 Apr 2006, Marc G. Fournier wrote:

The problem here is actually that two postgres instances are trying to use the same sempahore when they are actually different postgres instances.

No, the problem here is that kill(PID, 0) reports that a PID is 'not in use' when, in fact, it is, but in a different jail ... can someone explain to me how 'not hiding that fact' increases information leakage, or causes a security problem? I could see it if I could then proceed to kill that process from a seperate jail, but I don't see what as possible ...

So if it's using a different semaphore, why is it finding the semaphore of another Postgres session and trying to use that? The problem you're describing is a property of a collision on a semaphore. If there's no semaphore collision, how would it ever find the pid from another jail?

Robert N M Watson
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [HACKERS] semaphore usage "port based"?
    ... On Mon, 3 Apr 2006, Robert Watson wrote: ... not another process is running when it tries to allocate a semaphore ... ... under 4.x, kill*would* return that a process is running, even if it was in another jail, altho the jail issuing the kill can't see that process, so postgresql would go on to 54320002, and test that ... ... The problem here is actually that two postgres instances are trying to use the same sempahore when they are actually different postgres instances. ...
    (freebsd-stable)
  • Re: [HACKERS] semaphore usage "port based"?
    ... another process is running when it tries to allocate a semaphore ... ... 4.x, kill*would* return that a process is running, even if it was in another jail, altho the jail issuing the kill can't see that process, so postgresql would go on to 54320002, and test that ... ... The problem here is actually that two postgres instances are trying to use the same sempahore when they are actually different postgres instances. ... In the event we get virtualization of System V IPC, they can use the same semaphore ID to get different semaphores, but as long as the same ID points to the same sempahore for different instances, it's not going to work. ...
    (freebsd-stable)
  • Fwd: Jail is pausing . . Ideas please. . ?
    ... Semaphore system calls allow processes to synchronize execution by doing a set of operations atomically on a set of semaphores. ... I had two scripts that run on this jail, they both connect to the database jail that is running on the same host. ... gettext-0.14.5_1 GNU gettext package ...
    (freebsd-questions)
  • Re: [HACKERS] semaphore usage "port based"?
    ... wouldn't want to be able to SIGKILL the process from a different jail, ... The problem is that PostgreSQL uses killto determine whether or not another process is running when it tries to allocate a semaphore ... ... Robert brought up a good point, about recycled PIDs, but Tom Lane's response to that about the fact that we don't care if the process that is running is the one *actually* holding the semaphore, we'd rather err on the side of caution and just move on ... ...
    (freebsd-stable)
  • Re: [HACKERS] semaphore usage "port based"?
    ... If you're in a jail, ... not another process is running when it tries to allocate a semaphore ... ... altho the jail issuing the kill can't see that ... process, so postgresql would go on to 54320002, and test that ... ...
    (freebsd-stable)