Further, since we are blocking on the serial port, I have to question whether or not this should be a default enabled source. The other serial terminal DS is SmartOS, which is disabled by default. There are a lot of good reasons why people attach serial consoles, but assuming that it safe for cloud-init to read/write to a serial console seems like a great way to break infrastructure or control planes.
IMHO, I think that the fix should be twofold 1) disable this ds by default; 2) enforce a reasonable time out. I've attached a rough patch of what I am thinking here.
We should get CloudSigma to clarify what the timeout should be before we enforce the timeout.
That said, I think that an SRU that disables the DS is warranted.
The culprit here is that there is no timeout on the serial console read/write.
From cloudinit/ cs_utils. py self.raw_ result) Serial( SERIAL_ PORT) write(self. request) readline( ).strip( '\x04\n' )
73 def __init__(self, request):
74 self.request = request
75 self.raw_result = self._execute()
76 self.result = self._marshal(
77
78 def _execute(self):
79 connection = serial.
80 connection.
81 return connection.
Further, since we are blocking on the serial port, I have to question whether or not this should be a default enabled source. The other serial terminal DS is SmartOS, which is disabled by default. There are a lot of good reasons why people attach serial consoles, but assuming that it safe for cloud-init to read/write to a serial console seems like a great way to break infrastructure or control planes.
IMHO, I think that the fix should be twofold 1) disable this ds by default; 2) enforce a reasonable time out. I've attached a rough patch of what I am thinking here.
We should get CloudSigma to clarify what the timeout should be before we enforce the timeout.
That said, I think that an SRU that disables the DS is warranted.