[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
System V Shared Memory File-Based Interface
From: |
Marcus Brinkmann |
Subject: |
System V Shared Memory File-Based Interface |
Date: |
Thu, 17 Feb 2005 13:57:02 +0100 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
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
- glibc changes, Barry deFreese, 2005/02/09
- Re: glibc changes, Marcus Brinkmann, 2005/02/09
- System V Shared Memory File-Based Interface,
Marcus Brinkmann <=