Re: semaphore usage "port based"?

On Sun, 2 Apr 2006, Tom Lane wrote:

> Oops.  Here is the problem: kill() is lying by claiming there is no such 
> process as 83699.  It looks to me like there in fact is such a process, but 
> it's in a different jail.
>
> I venture that FBSD 6 has decided to return ESRCH (no such process) where 
> FBSD 4 returned some other error that acknowledged that the process did 
> exist (EPERM would be a reasonable guess).
>
> If this is the story, then FBSD have broken their system and must revert 
> their change.  They do not have kernel behavior that totally hides the 
> existence of the other process, and therefore having some calls that pretend 
> it's not there is simply inconsistent.

FreeBSD's mandatory access control models, such as multi-level security, biba 
integrity, and type enforcement, will generally provide consistent protection 
under the circumstances you describe: specifically, that information flow 
invariants across IPC types, including System V IPC and inter-process 
signalling, will allow flow only in keeping with the policy.

However, I guess I would counter with the following concern: the PID returned 
by semctl() has the following definition:
     GETPID       Return the pid of the last process to perform an operation                  on semaphore number
semnum.

However, pid's in general uniquely identify a process only at the time they 
are recorded.  So any pid returned here is necessarily stale -- even if there 
is another process with the pid returned by GETPID, it may actually be a 
different process that has ended up with the same pid.  The longer the gap 
since the last semaphore operation, the more likely (presumably) it is that 
the pid has been recycled.  And on modern systems with thousands of processes 
and high process turn-over (i.e., systems with CGI and other sorts of 
scripting),pid reuse can happen quickly.  Is your use of the pid here 
consistent with fact that pid's are reused quickly after process exit?  Use of 
pid's in UNIX is often unreliable, and must be combined with other 
synchronizing, such as file locking on a pidfile, to ensure that the pid read 
is valid.  Even then, you can't implement atomic check-pid-and-signal using 
current UNIX APIs, which would require a notion of a process handle (or, in 
the parlance of Mach, a task port).

Another thought along these lines -- especially with the proliferation of 
fine-grained access control systems, such as Type Enforcement in SELinux, I 
would be cautious about assuming that two processes being able to manipulate 
the same sempahore implies the ability to exchange signals using the signal 
facility.

Robert N M Watson