System V Shared Memory File-Based Interface

[Marcus Brinkmann]

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