David Lee wrote:
Until now, "ipctest" seems only to have been able to test the "pair" parts
of "ipcsocket.c", not the parts that handle connections amongst unrelated
processes.
Attached is a patch to "ipctest.c" to exercise those parts. By invoking
it with the additional argument "-c <n>", it sets up a server and <n>
clients and runs the existing tests through the client/server access
points. (The "-c" means "clients".)
(Actually, the only valid value of "<n>" at present is "1": single client.
But that's still far more functionality than was there before, and you are
welcome to add multi-<n> capability for yet extra flexibility...)
I propose applying this later this week; please feel free to peer-review
it first.
Someone had made a comment about "/tmp/foobar" being a poor name. If I
recall correctly (and it is very vague!) this problem should minor in this
testing context. But if it needs fixing, even if this context, then give
me a little detail and point me in the right direction.
You need to not have a predictable file name for the socket. You can
use tmpfile or generate a random number or use a process id, or pretty
much anything else to have an unpredictable name for the socket.
But, I'm not sure that this can cause a problem with sockets, since I
think the socket system call ensures that you can only talk to a socket.
The exploit was to cause you to overwrite some important file with
your privileges and cause a denial-of-service.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
