Ubuntu
cloud-init package

hostname unchangeable / some daemon changes and resets /etc/hostname

Bug #1780867 reported by Hadmut Danisch
280
This bug affects 4 people
Affects Status Importance Assigned to Milestone
subiquity
Fix Released
Critical
Michael Hudson-Doyle
cloud-init (Ubuntu)
Invalid
High
Unassigned

Bug Description

Hi,

I just ran into a strange problem with renaming a machine:

I've configured a new machine (HP Microserver with 18.04 server edition) in order to replace an older one, and thus gave it a temporary hostname serverx.

After finishing all configurations and removing the old machine named server, I tried to rename the new servers hostname from serverx to server.

I've tried that six times by either manually editing /etc/hostname or using hostnamectl to set the new hostname 'server', and the file /etc/hostname has provably been changed to 'server', but after rebooting the machine always comes up with the old hostname 'serverx', and even the /etc/hostname file is reset to 'serverx', which a fresh file mod date.

I'm not sure what does that reset of the hostname and modifies /etc/hostname, but since systemd is almost always the source for all sorts of trouble, I guess it is a combination of the DHCP reply and systemd.

I currently see no clean and regular way to change the hostname of this machine. Whatever I do, it comes up with it's old hostname. I don't even see what software component is changing the /etc/hostname,

That's a no-go and a security breach. No daemon or other software must ever change /etc/hostname without admin's consent.

If this is caused by cached DHCP responses, a fake (or faster) bogus DHCP server could push wrong hostnames into hosts.

Anyway, it is a severe security problem if a machine changes it's hostname in a way the admin doesn't want. That could cause lots of misconfigurations (e.g. when configuring machines with tools like puppet or ansible, get wrong IP addresses from DHCP, wrong firewall rules and so on). It can cause severe denial of service problems and allow such attacks.

What the hell is changing /etc/hostname during boot?

Why is editing /etc/hostname oder using hostnamectl not effective and violating it's own man pages?

Seth Arnold (seth-arnold)
information type: Private Security → Public Security
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1780867/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Brian Murray (brian-murray)
tags: added: bionic
Revision history for this message
Hadmut Danisch (hadmut) wrote :

It's not caused by DHCP.

When entering recovery mode, /etc/hostname has already been replaced with the old hostname, although network is not up yet and dhcp hasn't happenend, while dmesg interestingly says to have set the hostname to the new name (probably in initrd), so systemd must have some place where it has stored the old hostname.

Revision history for this message
Hadmut Danisch (hadmut) wrote :

OK, I've found the problem.

Strange side observation: My power cable was loose, and when pulling the network cable to ensure there's no DHCP response, I accidently pulled the power cable as well, thus forcing the machine into a hard immediate shutdown.

After booting from that hard shutdown, the machine had the new hostname, but after booting again, the machine came up with it's old hostname.

reason:

The ubuntu server installation image (which I used to install that machine) contains cloud-init.

There's several configuration files in /var/lib/cloud/instance, e.g. user-data.txt cloud-config.txt obj.pkl. Some of them fresh, obviously modified or recreated today. Removing them solves the problem.

So the reason of the problem is: Although it's not a cloud machine, but a physical machine, ubuntu installs that cloud stuff. That cloud stuff should configure the machine exactly once, but keeps reconfiguring the machine at every boot time, resetting the machine to those settings entered at installation time.

which probably means, and that's a security problem, that it resets the admins user account and password to the settings at installation time. If the admin changes the password (e.g. because compromised), it would probably happen that the machine resets to the old password in the same way it sets the old hostname.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks for tracking down the cause Hadmut.

affects: ubuntu → cloud-init (Ubuntu)
Brian Murray (brian-murray)
Changed in cloud-init (Ubuntu):
importance: Undecided → High
tags: added: rls-cc-incoming
Revision history for this message
Chad Smith (chad.smith) wrote :

This feels a bit like subiquity should only provide hostname once via cloud-init. Setting hostname in #cloud-config will result in cloud-init setting this every boot

Chad Smith (chad.smith)
Changed in cloud-init (Ubuntu):
status: New → Invalid
Revision history for this message
Hadmut Danisch (hadmut) wrote :

Why is that bug set to invalid after recognizing a configuration problem?

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hadmut, 'invalid' in cloud-init, still 'new' in subiquity.

Thanks

Michael Hudson-Doyle (mwhudson)
Changed in subiquity:
status: New → Triaged
importance: Undecided → High
Francis Ginther (fginther)
tags: added: id-5c7005ca28674083fa893f95
Revision history for this message
Mike Rushton (leftyfb) wrote :

@chad.smith Why should subiquity change the default setting of cloud-init as opposed to just fixing the default setting in cloud-init? I feel the bug is in cloud-init and not in subiquity.

Revision history for this message
Ryan Harper (raharper) wrote :

subiquity is providing configuration to cloud-init to perform configuration on first boot already; cloud-init will happily do what it's told.

I think there are several options on the configuration provided to cloud-init. Subiquity can provide the hostname statically into the image and not ask cloud-init to set the hostname. If subiquity did provide hostname to cloud-init, it will need to set the hostname config policy to perform this operation only once (per-once) and not the default (per-boot).

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Everything subiquity does via cloud-init should be per-once not per-boot. One way of doing this would be to have subiquity generate a cloud-init late_command that disables cloud-init entirely but I don't know if that's a very tasteful solution.

Michael Hudson-Doyle (mwhudson)
Changed in subiquity:
importance: High → Critical
assignee: nobody → Michael Hudson-Doyle (mwhudson)
Michael Hudson-Doyle (mwhudson)
Changed in subiquity:
status: Triaged → Fix Committed
Michael Hudson-Doyle (mwhudson)
Changed in subiquity:
status: Fix Committed → Fix Released
Revision history for this message
Thomas Ward (teward) wrote :

Because this workaroudn is not defined here, this is a workaround in the interim:

Edit /etc/cloud/cloud.cfg and set preserve_hostname to 'True' for /etc/cloud/cloud.cfg in order for the hostname change to persist.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.