summaryrefslogtreecommitdiff
path: root/shared
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2019-07-16 09:24:25 +0200
committerThomas Haller <thaller@redhat.com>2019-07-16 10:48:30 +0200
commitadb51c2a7f05fd15b5a0c51c01a6a725201c8c4a (patch)
treed2ba1408bdeb3d242f8c890646c3a2b49c98d0fd /shared
parent1bee1f5530dec64f6f1206dc87626cae4f513b77 (diff)
downloadNetworkManager-adb51c2a7f05fd15b5a0c51c01a6a725201c8c4a.tar.gz
device: fix reapplying changes to connection ID and UUID
4 properties are not really relevant for an already activated connection or it makes not sense to change them. These are connection.id, connection.uuid, connection.autoconnect and connection.stable-id. For convenience, we allow to reapply these. This way, one can take a different setting (e.g. with a different connection.id or connection.uuid) and reapply them, but such changes are silently ignored. However this was done wrongly. Instead of reverting the change to the new applied connection, we would change the input connection. This is bad, for example with nmcli connection up uuid cb922f18-e99a-49c6-b200-1678b5070a82 nmcli connection modify cb922f18-e99a-49c6-b200-1678b5070a82 con-name "bogus" nmcli device reapply eth0 the last re-apply would reset the settings-connection's connection ID to what was before, while accepting the new name on the applied-connection (while it should have been rejected). Fixes: bf3b3d444c77 ('device: avoid changing immutable properties during reapply')
Diffstat (limited to 'shared')
0 files changed, 0 insertions, 0 deletions