Re: O_NOLINK for open()

On Thu, 13 Sep 2007, Gabor Gombas wrote:

On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:

System V shmem is right out because the IPC key is publicly
visible and there is no combination of permissions which
will allow sharing the segment with just one other process
(or at least just one other user). To my knowledge Linux's
implementation doesn't provide ACLs for SysV shmem. SGI's
proposed XPMEM suffers from the same problems for my purposes.

SYSV shared memory has the concept of separate creator and owner ID's,
so you can share the shmem segment between exactly two users. Just use
IPC_SET and set shm_perm.uid to the user ID of the peer process.

Hmm. This will work as long as the peer process is running setuid
to it's own unique user. Excellent idea! Since I need to make the
program setuid to avoid non-priveleged ptrace attacks, this is a
terrific solution.

I think your worries about permissions has been cleared by the other
posts, but there is still a problem: the client may call ftruncate() on
the file descriptor, and then your daemon will get a nice SIGBUS when it
tries to access the shared memory. Handling that gracefully may not be
trivial esp. if your daemon is multi-threaded. SYSV shmem is _much_
nicer when you want shared memory between unrelated/untrusted processes.

I'm actually not so concerned about the client -- that code will be
trusted as well. The problem I'm trying to solve is preventing any
non-priveleged code except the server and client from gaining access
to their shared memory area. With the feedback I've received from
this thread I think a solid design is emerging, some of which will
need to be solved by system configuration by the sysadmin.

Thanks,
Brent

--
Brent Casavant All music is folk music. I ain't
bcasavan@xxxxxxx never heard a horse sing a song.
Silicon Graphics, Inc. -- Louis Armstrong
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: O_NOLINK for open()
    ... implementation doesn't provide ACLs for SysV shmem. ... SYSV shared memory has the concept of separate creator and owner ID's, ... so you can share the shmem segment between exactly two users. ... permissions of 0, immediately unlink it, and pass the file ...
    (Linux-Kernel)
  • Re: how to share variable across multi-processes
    ... >use strict; ... >comes from the strict buffer sizes when using shared memory. ... >the adjacent segment. ... >Which is why I usually just go with threads and shared variables, ...
    (perl.beginners)
  • Re: Quick questions on Shared Memory
    ... >> the shared memory segment, just detaches it ... > for both shmctl and shmget as well as a few others. ... > making me think that this structure is somehow filled when the segment ...
    (comp.unix.programmer)
  • Re: how to share variable across multi-processes
    ... IPC thru shared memory is the fastest available, ... the adjacent segment. ... pointers and return the correct value to the caller. ... Any modern OS should return SEGV on ...
    (perl.beginners)
  • Re: PHP & open connections
    ... client to pull the info on a regular basis. ... Shared memory isn't the problem. ... The problem is you cannot keep the connection open. ... Even then the browser and/or server are free to close the connection if they feel it's been open too long, and most browsers will have a limit as to how long they will wait for data. ...
    (comp.lang.php)
Loading