3

I have a massive file ie 1TiB owned as 'filehandler', permitted rwx------. I mmap(2)-ed it into the 64bit address space, and all works successfully. This file handled by a process running as user 'filehandler'.

Other processes request services from this handler process running as other user than the filehandler. They login into handler through unix socket. They communicate by IPC rules, all is ok.

The entire file must not be shared to requesters due to security reasons. In the file only some parts are allowed to access for requester processes.

The best performance will be given if share of the memory, just the allowed parts of the file with the requesting processes.

For example the shm gives the key to access the segment for other processes, it is a practical targeting to requester.

Is there any way to share only the allowed parts of a mmap(2)-ed space to any processes identified like shm technology?

Improve this question
5
  • 1
    do you have any selinux concern? Commented Feb 14, 2019 at 18:28
  • I do not. The security resolved enough by encryption, but more secure if not all are visible. Commented Feb 14, 2019 at 18:49
  • there's no way for a memory segment be given different permission bits to different parts of it. As every mmapd segment has a file associated, permissions are related to the permission bits of the file, so you'll only be able to access the whole file or nothing at all, depending on who are you when mmaping the file. Commented Feb 15, 2019 at 13:57
  • @LuisColorado: you could mprotect or munmap some pages of the mapping after calling mmap. But I don't think this helps for IPC unless you fork() and then have the child processes munmap the parts they don't need before dropping privileges or something. I don't think you can hand mappings over a socket. Commented Feb 15, 2019 at 14:44
  • im afraid the interest here is to give permission to access only to some part of the shared segment.... this is not what you are talking about. The resoure is shared as a whole, so you can attach if you have global access to it. but the region is up to you... you cannot be impeded to mmap some parts of the segment and allowed to other. Commented Feb 15, 2019 at 14:47

2 Answers 2

Reset to default
2

Is there any way to share only the allowed parts of a mmap(2)-ed space to any processes identified like shm technology?

TL;DR: No.

In more detail,

How to remap a file mmap(2)-ed in memory like shmget

mmap() and shmget()are not really comparable. A better comparison would be between the combination of shm_open() / ftruncate() / mmap() on one hand and the combination of shmget() / shmat() on the other. These are the main alternatives in POSIX for creating labeled shared-memory segments and mapping them into the process's address space. You should recognize there that the analog of shmget() is shm_open(), and the analog of mmap() in this context is shmat().

Now, returning to

Is there any way to share only the allowed parts of a mmap(2)-ed space to any processes identified like shm technology?

Note well that in both cases above, it is the object being mapped (a shared memory segment) that provides for sharing between unrelated processes, not anything to do with mmap() itself. The same applies when mmap() maps any other kind of object, such as a regular file. It is always the mapped object through which any shared access is mediated. It has to be this way, because a memory mapping is a property of one process -- it is not itself share-able.

Your design calls for a filehandler process to serve as gatekeeper to the data, rather than allowing clients to access it directly. That's fine, but it precludes the clients mapping the file into memory. You could probably arrange for client to access the data through a shared memory segment of either flavor, but that would require the server copying the right data out of the big file into the client's shared memory segment. That might indeed be something to consider, but you can forget about the server providing clients direct memory-mapped access to the file.

Improve this answer
Sign up to request clarification or add additional context in comments.

11 Comments

Yes, I can see the the incomparability furthermore I understand your suggest, it is always works. I hoped there is a way to avoid copying due to this file is a special database and possible be in very io intensive stages, too, when performs seeking or gathering anything. Even it would be better to export region to direct writable for user processes, instead of force to make the service process write data part copy to file.
The kernel's page system is really effective, advanced and convenient it would be sin not to apply it. Instead of the burden of the administration simply to apply the the machine instructions of the processor in its address space. So if I can not find any solution of my little problem I am ready to write an appropriate kernel module to build bridge between the mmap and shm system with some extras.
@apexik, what you appear to want is a new kind of kernel-managed object representing a view of a region of a file, with ownership and / or permissions set independently of those on the underlying file. I am inclined to think that developing this and the needed system interfaces for creating and manipulating them would be a much larger and more difficult task than you anticipate, but if you're determined to do that then don't let me stop you. Still, it would be worthwhile to consider alternatives, such as, say, splitting up the file into smaller ones that clients may map directly.
you are completely meshing the answer by mixing shm_* system calls (which are for AT&T Unix shared memory segments, a completely different thing than BSD Berkeley mmap(2) system call, which forces a file to be associated to a memory segment and that has nothing to do in the internal implementation) There's no compatibility between them and no relationship. Sorry for the downvote. By the way, as I understand, when the PO talks about shm technology, he is talking always from the point of mmap and never from shmget (that has no possib. or connection to files)
Please look again, @LuisColorado. Yes, shmget is part of the SYS V IPC suite, and it goes with shmat, not mmap. This answer already says that. But the shm_* functions, such as shm_open, are part of the POSIX IPC suite, and they do get used with mmap(). In any case, the main thesis of the answer is the same thing you wrote in your comment: mmap() does not itself provide any form of IPC. It is the thing that is mapped -- whether a file or a (POSIX) shared memory segment that does. Or a Sys V shared memory segment, which is not file-based nor mmapped.
|
1

There's no connection between implementations of shmget system call (a System V AT&T derived implementation) and mmap (a berkeley's BSD system derived implementation) It's true that in BSD systems, AT&T shared memory is implemented by using mmaped private segments with no file attached, but that's of no use also, because you need the shared segment to be associated with a file.

As you need, the only possibility to share memory segments related to a file's contents are by using mmap system call, because System V shared memory segments have no means to associate a file with them.

All of these resources (either SysV or BSD) have a set of permissions bits associated with them that allow them to be used with some security, but as happens with files, only in a global (the entire resource) way, making you able to access the whole thing or nothing at all.

BTW, you can implement what you want by means of copying segment contents to a different, private, segment (only the size you want the client to be allowed to see) only the segments it is allowed access, and this way you can have finer control over whom and what the clients are allowed to do.

And last, remember that this approach requires copying of segments of shared memory, so you need to remember to copy back the exported segment for a customer if you don't want the modifications made by that client to be lost when the client finishes using them.

From my point of view, you are complicating things a little, but you better know how your application is designed than me.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.