bytevolc...@safe-mail.net writes: > Hello, > > I am writing a local server which requires the use of shared memory > objects. Essentially, other applications communicate to this server by > connecting to a UNIX domain socket within the file system. > > Occasionally such an application may require a shared memory buffer to > share large quantities of information with the server. In doing this, > the server uses shm_mkstemp(3) to create the shared memory objects, and > then sends the file descriptor over the connection. > > char snm[25] = "/tmp/megaserv/XXXXXXXXXX";
I doubt that our shm_open(3) implementation will respect the path you provide here. > int fd; > > fd = shm_mkstemp(snm); > > /* Error handling omitted for clarity. */ > /* Potential race condition here */ > > shm_unlink(snm); > > ... > > /* Send fd over connected socket. */ > > Whilst the setup I have works well, I see a potential race condition, > albeit a very small one, in the position indicated above; an external > process, malicious or otherwise, can connect to the object in between > the shm_mkstmp() and shm_unlink() calls. Not if the permissions on the file prevent this. "This implementation forces the mode to be 0600 or 0400, and prohibits sharing between different UIDs." > Furthermore, there is a small possibility for a stale file to be present > in the file system, should there be a crash. Why not trust the promise made by shm_mkstemp(3)? > Is there a way of creating these objects without having to actually > create a file in the file system, something like pipe() or socketpair()? > > For example: > > int shm_create(int flags); > > That would basically eliminate the race condition, the possibility of > a stale object, and make shm_unlink() unnecessary in this case. > > Any advice/suggestions? > -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
