[erlang-questions] Ports and their owners

[Musumeci, Antonio S]

>From a language / VM perspective it should be quite simple to include the sender as part of the message. At this point it may not be possible to add without major breakage but it's very unfortunate that was not the initial design.

I agree the original pure message passing syntax is cleaner... though as the docs say otherwise.

Perhaps open_port/2 could be expanded to take an argument limiting messages to only those from the owner. I've not tracked down the entire flow of port_command but it looks like do_port_command in erts/emulator/beam/erl_bif_port.c takes a Process* which I'm assuming is the data structure representing the process calling port_command... If so it can error if that option was set and the Process->id is not that of the port's owner.

-----Original Message-----
From: Robert Virding [mailto:rvirding@REDACTED] 
Sent: Wednesday, February 17, 2010 10:03 AM
To: Musumeci, Antonio S (IT)
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] Ports and their owners

The original port communication mechanism is the purely message based one. It was designed to follow the standard erlang process communication mechanism as closely as possible, which is why the sender must include its own pid in the message. The security of communicating with a port would then be at the same level as process communication. Erlang was never really designed to be secure *within* a node and it is basically impossible to protect yourself internally.

IIRC port_command was added to bypass the need to communicate via the port owner process. For what exactly what reason I can't remember.
Personally I have always felt that the pure message passing is much cleaner and better fits into the rest of Erlang.

Robert

On 17 February 2010 15:11, Musumeci, Antonio S <Antonio.Musumeci@REDACTED> wrote:
> Given:
>
> 1) Port ! {self(), {command, Data}} syntax will fail with badsig if the self() is not the port owner.
> 2) port_command(Port, Data) does not do this and allows any process to 
> send messages to the port
> 3) ports have owners
>
> Question:
>
> Why is it (or am I missing how to do it) that I'm unable from the port side to find out who is sending the incoming message? It appears that there was this original intent to lock down the port but with port_command that was thrown away without the ability to be sure who's sending you the data so as it implement one's own security measures.
>
> If this is in fact true does anyone have suggestions on securing ports?
>
> Thanks.
>
>
> ----------------------------------------------------------------------
> ----
> NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
>

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.