[Setup-tool-hackers] Re: bacon-message-connection (was Re:Shipping Vera with 2.4)
- From: Michael Meeks <michael ximian com>
- To: Bastien Nocera <hadess hadess net>
- Cc: Havoc Pennington <hp redhat com>, GNOME Desktop Hackers <desktop-devel-list gnome org>, GST <setup-tool-hackers ximian com>
- Subject: [Setup-tool-hackers] Re: bacon-message-connection (was Re:Shipping Vera with 2.4)
- Date: 28 Feb 2003 09:41:51 +0000
On Thu, 2003-02-27 at 18:08, Bastien Nocera wrote:
> It's simple, and only sends strings. The server is an existing instance
> of the application. That's why the protocol is so simple.
Whatever - the total line count is greater and more fragile than that
in gnome-terminal to do a similar thing; also - you could have re-used
'linc' which provides a low-level connection layer such as you have
> > There are also the following bugs/mis-features I saw with a brief
> > glance, correct me if I'm wrong:
> > * missing syscall error handling
> I check the return values of all the syscalls. What did I miss exactly?
eg. 'listen' - unlikely but ... ;-)
> > * blocking accept
> No, it's in a different loop, thanks to the usage of GIOChannel.
Uh ? in a different loop ? in a different thread ? it didn't look like
that at first glance:
If no pending connections are present on the queue, and the
socket is not marked as non-blocking, accept blocks the caller
until a connection is present.
> > * not handling EINTR
> See Havoc's mail
Which talked about D/BUS syscall wrappers ? which AFAICS you are not
EINTR The call was interrupted by a signal before any data was
> > * blocking connection write
> Usually the client's only purpose is to send messages to the server
> (already running instance) and exit. So it is appropriate.
Fair enough; write can also take EINTR.
> > * server_cb locks in a tight loop on 'read' error
> That needs a test for EIO which is the only error that could really
> happen in this case.
EIO ? that seems somewhat unlikely to me from the description; what
happens if your remote app SEGVs when it's having data pushed at it?
> > * looks like it creates an insecure, world writable /tmp
> > Unix domain socket -> instant, huge security hazard
> As I said, it's user writable only. I'm not *that* stupid.
Where is the code that makes it user writable ? furthermore, are you
aware that several Unixalikes don't honour permissions on sockets - you
have to secure them in a user-owned, non-world-readable directory ? (eg.
> > * doesn't do collision checking => instant DOS attack.
> If the user wants to DOS his own application, well, that's his right. He
> could also load a 500 megs TIFF image in the GIMP and lock his machine
> up. That's his problem.
So what happens if I log into your machine and create a file called
/tmp/totem.hadess ? [ _AND_ I am not user 'hadess' but you are ].
Perhaps totem is only suitable for use on single-user machines.
firstname.lastname@example.org <><, Pseudo Engineer, itinerant idiot
setup-tool-hackers maillist - email@example.com
] [Thread Prev