Re: AlphaServer resource leak

[Lars H. <Lar...@re...>]

Joachim Kock skrev:
> Hello Lars,
> 
>> There is a resource leak in the alphaServer package, in the form of a
>> channel that stays open after we're done with it.
> 
> Good catch!
> 
> I agree with all you points.
> 
> I have committed your minimal fix.
> 
>> one might wonder whether this initial connection is at
>> all necessary. Methinks specifying -myaddr 127.0.0.1 in the [server
>> -socket] call, and only accepting connections from address 127.0.0.1,
>> would provide the same level of security.
> 
> I think you are right.  The whole initPhase business looks superfluous.
> 
> I cannot see right now what the issue could have been that prompted
> these workarounds.  But perhaps something like this.  Suppose the
> machine has a real IP address, and that this address is how the
> machine is identified in incoming connections.  This would count as
> distinct from the string 127.0.0.1 although of course they are just
> different names for the same machine.  The idea was maybe that the
> initial connection should take note of how the connecting script
> identifies itself, hoping that all subsequent connections identify
> themselves by the same string.

It seems reasonable that

   socket [info hostname] $port

might lead to such behaviour, but I have vague recollections of a 
discussion that some OSes discovered that the above was just localhost 
and connected at that interface instead.

> I say that this is what I imagine can have been the explanation.
> But now I am thinking, like you, that since both init script and
> alphac connect to "localhost", the connecting script will automatically
> choose the local interface (lo0) and thereby identify itself as 127.0.0.1.
> (In contrast, I think that if the IP number were 192.168.1.2, and if
> the connecting script tried to reach the alpha server at 192.168.1.2,
> then the interface used would be en0 or something, and then the
> identification of the incoming connection would also be 192.168.1.2,
> and then the server would reject the connection since this string does
> not match 127.0.0.1.)
> 
> Do you have further insight before I simply remove all that initPhase
> stuff?

Not about that specifically, no.

I have for the last year or so done quite some thinking about how 
unrelated Tcl processes may communicate, however. (The proper solution 
is Unix domain sockets, but access to those are only provided by the 
ceptcl extension AFAICT.) [socket]s are easy in Tcl, but provide no 
protection against pranks by other users. Some measure of protection 
could be obtained by generating a random cookie, store it in a file 
that only the right user can read, and then require AlphaServer clients 
to provide this cookie...

> PS:
> 
>> Then there's the complication that nothing stops other users on the
>> same machine from connecting to the alphaServer port and sending
>> commmands (which if I recall it right can't do much more than opening
>> windows, but we know from the Web that this can annoying enough). I
>> suppose strengthening the established protocol might be hard, 

...but that it a protocol change.

Generally, I've found that named pipes can be used as an alternative to 
sockets, although it's not entirely straightforward. A pure tclsh 
process need to [exec] mkfifo to create named pipes, opening them 
without blocking is not entirely straightforward, and you need two 
pipes if you want bidirectional communication, but it's quite doable.

A case that I wouldn't mind seeing supported is AppleEvent 
communication with support for alphac -wait. (Sometimes the 
-AlphaServerPort file gets deleted, for no apparent reason.) As I 
understand it, AlphaX only needs to be able to send an "it's OK to 
proceed" signal to alphac in this case, but there is the catch that Tcl 
doesn't have general signal processing built in. A workaround might 
however be if alphac spawns a child process and sits waiting for /it/ 
to quit, since if AlphaX is told the [pid] of that child process in the 
original call, then AlphaX can kill the child without damaging the 
parent alphac process.

>> but a
>> simple step forward would be to prevent other users from reading the
>> -AlphaServerPort file (specify permissions in the [open] on line 274).
> 
> Sounds right.  What is the correct way of setting the permissions?

0600 as the third argument of [open], I'd say.

>> Also, what is the state of art for specifying the path to alphac, now
>> that it's typically hidden deep within the AlphaX bundle? Not
>> everything that might need to call alphac inherits environment from Alpha.
> 
> Following a tradition started by BBEdit and TextMate, Alpha now has
> a symlink to alphac at AlphaX.app/Contents/Resources/alphac
> 
> This is probably what should be advertised, but it is difficult to
> automatise further, since we don't know in advance where the binary is.

Yes, that's the problem. It would be useful with a link somewhere more 
predictable, but it's not easy to say where that would be. Possibly 
something could be put in ~/Library/Application Support/AlphaX?

> PPS:
> 
>> (Also, what are the serial channels?  A tclsh don't seem to have any.)
> 
> I don't see those serial channels.  They must come from something else.

More of a question for Bernard, I suppose. Also, the OS version might 
be relevant (I've got 10.4 on all my machines).


Lars Hellström