Yes, I've taken that into account. All shared memory is opened 0600.

The main point of that aspect of security is to preclude targeting of particular processes. All pipes connected to the server are available via /proc, also.

When I mentioned that the supposed detriment caused by not being able to attach to flagged memory segments was actually a useful feature, I meant that once the memory is flagged, nothing else can access it. By flagging it immediately after the client accesses it, nothing further may attach to it, thereby protecting it.

Really the only weakness of the shared memory over using pipes is possible corruption. I've got that covered, also, though. I've designed the flow so that clients can't force exceptions within the server by corrupting shared memory.
ta0kira

PS Here is the entire security policy if you'd like to see. It explains a little more about the server itself.
http://resourcerver.sourceforge.net/security.html

I'll investigate resourcerver at some point. Thanks!

I look forward to your comments. I'd say I'm within a month of release except I've got quite a bit going on over the next several months, so I can't safely say that.

I'm considering an additional fork for servers which have shared memory enabled. How it would work is the parent process would be the shared memory reaper and the child process would be the server. When the server needed a new segment it would pass a request to the parent (possibly via SIGIO,) which would send a private ID and would give the server a few seconds to attach. It would keep a table of the segments and every 5 seconds or so would check them all and flag all with no attached processes. It wouldn't share the process group of the server to prevent signals from being passed up, and it would nonblocking-waitpid each iteration until server exit. The hardest part will probably be setting it up so the user can enable/disable the extra fork from the command line. But hey, I already have it working with dual-mode pipe/shared-memory within the same server instance! Shouldn't be a problem.
ta0kira