INET SETOPTS

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

INET SETOPTS

Valentin Micic-6
Hi all,

At the present moment (and this seems to have been the case in the past as well), any process that have an access to 'Sock’ may issue a successful call to inet:setopts( Sock, [{active, Flag}] ).
Is it safe to presume that this is going to stay this way going forward, or, are there plans to change this behaviour to allow, say, only “controlling process” to issue such command?

Thanks in advance.

V/
Reply | Threaded
Open this post in threaded view
|

Re: INET SETOPTS

Raimo Niskanen-11
On Thu, Nov 21, 2019 at 03:19:15PM +0200, Valentin Micic wrote:
> Hi all,
>
> At the present moment (and this seems to have been the case in the past as well), any process that have an access to 'Sock’ may issue a successful call to inet:setopts( Sock, [{active, Flag}] ).
> Is it safe to presume that this is going to stay this way going forward, or, are there plans to change this behaviour to allow, say, only “controlling process” to issue such command?

We will not change existing API:s such as inet:setopts/2, but a new
API, for example socket + net, may benefit from protecting especially options
that control process communication such as {active, Flag} to only be used
by reasonable processes (the controlling process).

>
> Thanks in advance.
>
> V/

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Reply | Threaded
Open this post in threaded view
|

Re: INET SETOPTS

Valentin Micic-6
Thank you Raimo.
Much appreciated.

Kind regards

V/


> On 21 Nov 2019, at 16:11, Raimo Niskanen <[hidden email]> wrote:
>
> On Thu, Nov 21, 2019 at 03:19:15PM +0200, Valentin Micic wrote:
>> Hi all,
>>
>> At the present moment (and this seems to have been the case in the past as well), any process that have an access to 'Sock’ may issue a successful call to inet:setopts( Sock, [{active, Flag}] ).
>> Is it safe to presume that this is going to stay this way going forward, or, are there plans to change this behaviour to allow, say, only “controlling process” to issue such command?
>
> We will not change existing API:s such as inet:setopts/2, but a new
> API, for example socket + net, may benefit from protecting especially options
> that control process communication such as {active, Flag} to only be used
> by reasonable processes (the controlling process).
>
>>
>> Thanks in advance.
>>
>> V/
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB