[LU-17382] LNet: allow dynamic setting of "accept" parameter Created: 21/Dec/23  Updated: 22/Dec/23

Status: Open
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Serguei Smirnov Assignee: WC Triage
Resolution: Unresolved Votes: 0
Labels: lnet, security

Issue Links:
Related
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

By default, LNet is accepting connections only from "secure" (<1024) ports. If there are clients connecting using a wider range of ports, e.g. via NAT, the server is expected to have set lnet module parameter "accept" to "all", otherwise out-of-range connections are rejected with an error similar to the following:

LNetError: 6508:0:(acceptor.c:430:lnet_acceptor()) Refusing connection from 10.49.76.116: insecure port 60694

Currently to change the value of the "accept" parameter it is required to modify the /etc/modprobe.d/lustre.conf file and reload the module. It is proposed to allow setting "accept" parameter dynamically - it is less disruptive to do so compared to having to reload LNet just because a few clients using NAT got added.



 Comments   
Comment by Andreas Dilger [ 21/Dec/23 ]

Sebastien, it is probably not (easily) possible to accept connections from insecure ports based on a nodemap? That is probably a chicken-and-egg issue where we can't check the nodemap until after the connection is established? I guess for a more secure environment, it is better to have strong authentication (SSK, Kerberos) and then accepting connections from insecure ports is not really a concern...

Comment by Sebastien Buisson [ 22/Dec/23 ]

Yes exactly, nodemap operates way above LNet, so I am not even sure we could have access to the LNet port? I do not really know why the ports below 1024 are called secure actually. Maybe it is more that those ports can be assigned to "services", so there is no risk of having the port used by someone else?

Comment by Andreas Dilger [ 22/Dec/23 ]

Ports below 1024 cannot be opened by non-root processes, so in environments where the nodes are secure/trusted this means that services using those ports are also more secure.  With modern systems where any user can install the client and/or run as root this is less useful.

Generated at Sat Feb 10 03:34:59 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.