Hi, > At Wed, 9 Feb 2005 13:03:17 -0500, > Barry deFreese wrote: > > Roland, marcus, etc, can someone comment on the following patch neal made > > two years ago for sysv shared memory? > > > > http://lists.gnu.org/archive/html/bug-hurd/2002-04/msg00288.html
Here is a list of issues I found, and how they can be fixed potentially. For each of these, we have to make a decision how important they are, and if a more correct implementation can be defered to later. * In Sys V IPC, IPC permissions are managed via a creator uid/gid, and an owner uid/gid and a mode. As both the creator and the owner have equal access to a shared memory object (both can delete it, both can change the current owner, etc), and we don't have any filesystem feature that gives us a way to express such permissions, this can not be implemented without filesystem extensions. In fact, this can not even be implemented with a filesystem extension like ACLs (one of my ideas was to map the creator uid/gid to the Unix file owner and the owner uid/gid to an entry in the ACL list for the shared memory object - but this has quite different semantics than the IPC perm stuff). I'm out of ideas for this one. I suppose if this is an unused obscure feature we can get away with always setting uid==cuid==file owner and gid=cgid==file group and just not allow changing the uid/gid of a shared memory object with shmctl's IPC_STAT command. * In Sys V IPC, the shmid, which is a global identifier associated with a shared memory object, has a sequence number in the high bits to make it unique over time. The current implementation uses the inode as shmid, but this has no such sequence number. One idea would be to export the inode generation number that is used by some modern filesystems and export it in the stat interface (this seems to be a desirable feature anyway - Linux allows to read it with a ioctl, but seems to be moving to export it in the statbuf because the ioctl has only limited use). Then the shmid can be a combination of the inode number and the generation number. The only issue with that is that then the "int" for the shmid is too small! There is a minimal problem in using the inode number anyway, as an inode number is an unsigned long, and for all I know ULONG_MAX is a valid inode number but would map to -1 in a shmid (and to negative numbers in general, which may break bug-by-bug compatibility with programs checking for <0). Ok, so more than 2^31 inodes is very unlikely to happen, and if they are allocated from 1 it's not an issue. So on normal filesystems we should be fine (just let's hope that nobody gets funny ideas about using the high bit of an inode to encode some information). The sequence number is supposed to be available in the ipc_perm structure in the seq field. On GNU/Linux, this field is a short int __seq and its content is non-sense (certainly not the sequence number used by the kernel, as it's always the same for me). So maybe we can get away with never using any sequence numbers. * In Sys V IPC, the nattch field of the struct shmid_ds tells you how many shmat are currently active. This is an important feature, because it tells you if there are extinct users of a shared memory object. However, as a shmat translates just to an io_map, this basically means we have to tell how many mappers there are. Not possible, but we can provide the number of send rights to the memory object. The only thing we have to ensure here I think is that if there are no users it will be 0, if there is 1 user it will be 1, and it will be >1 if there are more than one user. If the shmat operation always requests the memory object with io_map, and the shmdt operation always releases the memory object, then the number of send rights in the server should show the above behaviour. This requires a small filesystem extension to retrieve the number of send rights for the memory object of a file (and optionally can give you information about the number of users of the file etc if that is easily available). Note that I have seen code testing nattch == 0/1. * The PID of the creator and of the last process doing an operation on the shared memory object is also available in the shmid_ds struct. We can not provide this information reliably without a pid_reauthenticate operation with proc server support (a la io_reauthenticate and auth). This was also the case for a similar issue with sockets, IIRC. Well, we can probably get away with setting this field to 0 always. I am not for letting the creator or others volunteer this information, as they could provide a faked identity that could be a security risk. * The struct shmid_ds also contains information about the time of the last attach and the time of the last detach. Both of these times must be volunteered. The problem is that they may be volunteered by read-only users. The time of the last detach may be unnecessary. The time of the last attach sounds potentially useful. I am not sure what to do. Maybe we can just use the access time of the file. This would only be modificable by at least read-only users (not by users with no access rights). It would probably not be accurate. But it may be good enough for common uses, if any (timeouts?). Needs more knowledge about common uses. * There is also a ctime, which is the last change time by shmctl (ie, IPC_STAT). This seems to be totally in sync with the mtime of the file, so we probably can use that. * As Neal pointed out, RMID will not destroy extinct mappings, but this doesn't seem to be a problem as no existing system behaves this way. Unlinking the file will at least invalidate the inode number, and thus the shmid associated with the key. Here the sequence number becomes quite relevant I'd say. As the SysV SHM interface is quite ugly, I don't think we should necessarily strive for standard compatibility, _if_ we can get away with just supporting what applications need while being secure and robust. Before actually committing to an implementation we should look at how the interfaces are actually used in common software. I have not done that systematically at all yet. So, in summary: Basic operations that are actually used by applications likely can be provided with one minimal filesystem operation: 1. Retrieve the number of send rights to the memory object. For better reliability, a second extension is proposed: 2. provide the inode generation number in statbuf. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
