hello. Ok. I figured out the answer. And, yes, it's obvious, as I
suspected.
Mouse had it right. The problem is that both sshd and imapd, the two
processes I was interested in looking at, while not having the setuid or
setgid bits set in the filesystem, do perform a setuid(2) as part of their
normal processing. Once done, they do not fork and exec any new processes,
thus causing the P_SUGID bit to be set on the processes I was interested in
looking at. ps -o flags -p <pid> told me what I needed to know to explain
this problem. For reference, I used the ktrcanset() function from
kern_ktrace.c from
NetBSD-3.0 sources because it was easier to read than following the chain
of layers down through the secmodel infrastructure and finding where
exactly the permission is denied in that machinery.
-thanks
-Brian
