Odd, Isn't 777 insecure for shared memory segments?
On Sat, 23 Sep 2000, David Ford wrote:
> (cc: to [EMAIL PROTECTED] and to [EMAIL PROTECTED] - this
> should be the last post to LKML for this subject)
>
> Known historical items:
>
> -All shm segments get used up in very fast order.
> -Everyone noticing it maintains it is 4.01c versioned
> -It happens on multiple versions of Linux kernels, 2.2 and 2.4 (no other
> OS in tests)
>
> New items:
>
> - I did a completely fresh checkout of X a few hours ago and built it
> modular, I now get the shm bug
> - I have -not- changed my kernel but I have changed kernel source.
> - X itself doesn't seem to be getting the SHM segments but child
> processes are and someone isn't detaching from them, particularly
> starting enlightenment causes a flurry of SHM allocations.
>
> The sequence of events by my running gdb on both X and enlightenment and
> trapping all shm calls is this:
>
> enlightenment creates and attaches to a segment
> X attaches
> they chit chat over the shared mem
> enlightenment detaches and destroys the segment
> X remains attached to the segment
> ...repeat until exit
> at exit of X, segments are detached by default
>
>
> (gdb)
> E Breakpoint 1, shmget (key=0, size=32768, shmflg=1023)
> E Breakpoint 4, shmat (shmid=567279622, shmaddr=0x0, shmflg=0)
>
> ipcs refcount=1
> X Breakpoint 13, shmat (shmid=567279622, shmaddr=0x0,
> shmflg=0)
> ipcs refcount=2
> X Breakpoint 15, shmctl (shmid=567279622, cmd=2,
> buf=0xbffff1fc)
> (buffer write/reads)
> E Breakpoint 2, shmdt (shmaddr=0x40014000)
> ipcs refcount=1
> ipcs shmid marked destroyed
> X is still attached to this shmid, it will not do anything
> else on this shmid for the remainder of it's life.
>
> Interim conclusion:
>
> X is at fault. Linux kernel is fine. X simply doesn't detach any of
> these client requested segments. It -does- detach the segments it
> started itself.
>
> That being said, it is very possible that X (and other processes)
> depended on a default action. Recently SHM handling changed in the
> Linux Kernel which is still correct but may tickle processes that need
> to have code updated. I suspect X simply needs the shm handling
> tweaked. I've diffed the CVS code all the way back to April and there
> are no relevant SHM changes. Above we see that X does an shmctl() with
> IPC_STAT as the cmd, but never detaches from it. As we see below, X
> calls shmdt() the next time it gets a message from the client. In the
> current CVS code it never calls shmdt()
>
>
> Here's a paste of a working X compiled and installed on September 4th.
>
>
> E - Breakpoint 4, shmget (key=0, size=32768, shmflg=1023)
> 0x00000000 698023942 david 777 32768 0
> E - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0,
> shmflg=0)
> 0x00000000 698023942 david 777 32768 1
> X - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0,
> shmflg=0)
> 0x00000000 698023942 david 777 32768 2
> E - Breakpoint 2, shmdt (shmaddr=0x40014000)
> 0x00000000 698023942 david 777 32768 1
> Breakpoint 3, shmctl (shmid=698023942, cmd=0, buf=0x0)
> 0x00000000 698023942 david 777 32768 1
> dest
> E - Breakpoint 4, shmget (key=0, size=524288, shmflg=1023)
> E - Breakpoint 1, shmat (shmid=698056711, shmaddr=0x0,
> shmflg=0)
> 0x00000000 698056711 david 777 524288 1
> X - Breakpoint 2, shmdt (shmaddr=0x40015000)
> (first segment removed)
>
>
> Here is what enlightenment is doing (invert the part
> sequence):
> (gdb) bt
> #0 shmat (shmid=698089478, shmaddr=0x0, shmflg=0)
> at ../sysdeps/unix/sysv/linux/shmat.c:39
> #1 0x40091c77 in Imlib_render (id=0x81090f0, im=0x811d4a0,
> w=447, h=162)
> at rend.c:6468
> #2 0x8078d0a in SetBackgroundTo (imd=0x81090f0, win=2097191,
> dsk=0x8114430,
> setbg=1 '\001') at desktops.c:912
> [...]
> #2 0x4019396e in _XRead (dpy=0x8107e80,
> data=0xbfffc19c "\\\002\b\001q\030(J\001", size=32) at
> XlibInt.c:1032
> #3 0x4019428b in _XReply (dpy=0x8107e80, rep=0xbfffc19c,
> extra=0,
> discard=1)
> at XlibInt.c:1667
> #4 0x401900fe in XSync (dpy=0x8107e80, discard=0) at
> Sync.c:41
>
> [more to come - dinner calls - please feel free to comment and provide
> information]
>
> -d
>
>
>
> --
> "There is a natural aristocracy among men. The grounds of this are
> virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
