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