Perhaps this question is better suited for the programming forum, but I thought I'd try here first. I somehow got the crazy idea that I could design a virtual file system like gnome-vfs or KIO, and I'm now stuck with a bunch of design choices.

Anyhow, I'm considering implementing the VFS as a per-user daemon, which applications would connect to and post requests to. However, if I ever intend for this model to work, it must be secure. Now, since a lot of data could potentially be getting pushed between two processes, I must use extremely fast IPC, which is why I settled on shared memory.

The basic idea is that the daemon would simply have an open socket that it listened to. Other processes would generate a unique shared memory segment, then communicate its ID over the socket. Then the daemon would connect to that piece of shared memory and from then on do all its IPC through that.

Now, the trick is enforcing the per-user daemon thing. That is, how to prevent a user process from connecting to the root daemon, effectively gaining root permissions to the file-system? I was wondering if there was any way to get the PID of the other processes attached to your piece of shared memory? By the way, I'm talking about shmget() shared memory, not mmaped shared memory.

I thought about using mmap as a way of doing this - it would allow you to use file permissions to control this - have a directory that the daemon watches, and when a process wants to connect it creates a file with its PID as the file name. Set the file permissions so that only to user can read or write to it. The trouble with this is that it might lead to corruption if one process exits and another is created with that PID between scans. Then the new connection wouldn't be made.

Anyhow, is there any way to verify the identity of the process on the other end of a bit of shared memory?

wow, never mind - I feel stupid. Upon another reading of the manpage for shmget, I see that one can specify the permissions on a piece of shared memory.

Moved: This thread is more suitable in the Programming forum and has been moved accordingly to help your thread/question get the exposure it deserves.