Jeremie Courreges-Anglas wrote:
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.
Yes, it seems to create files with long names (that have nothing to do
with the template I provide) in the /tmp root.
If it doesn't respect the path or template, what is the point of having
this argument there in the first place, and what is the point of even
having a file on the file system?
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)?
" If a temporary shared memory object is desired, the shm_mkstemp()
function should be preferred as it avoids several possible security
holes that tend to appear in programs trying to create their own unique
temporary names. The template argument is a string with at least six
trailing Xs as described in mkstemp(3)."
I do not see any promises here. The only promise here is that the shared
memory object will be created atomically. I found it creates long-name
files with mode 0600. If the implementation promises these permissions
for shm_mkstemp(3), then fantastic; it should really be mentioned in the
man page though.
But I suppose if the malicious process is running as the user, then it
can wreak all kinds of other havoc on the system; no need to protect the
shared memory buffers then.
There's still an issue of the stale files on the file system, should
there be a crash, interruption, signal, or something like that. Even
with close(2), the file remains until shm_unlink(3) is called.
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?
