Comment by tetromino_ | Hacker News Reader

Comment by tetromino_ | Hacker News Reader

Parent Full thread

> How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname?

If you want the hostname to be preserved across reboots, you need to save it on disk - canonically, in the /etc/hostname config file.

Since /etc/hostname is an important per-machine config file, you probably want it owned by root.

Since you may want to edit this config file from a GUI control panel of some sort that you launch from a desktop environment running under a non-root user, you need a mechanism for the control panel process to be able to change the config file.

There are several ways to accomplish this:

* run the control panel process under root (for example, using sudo). This is not a good idea, especially under X11, since GUI toolkit libraries are not security hardened, have a large attack surface thanks to various GUI IPC mechanisms, and your control panel process could be subverted by hostile processes that have been waiting in the background for just such an occasion to arise.

* put your non-root user in a group which has write access to /etc/hostname. This is the traditional Unix solution, but it's not very flexible. If your user was not in the hostname-writer group, you will have to log out and back in for the change to take effect. And you can't create policies like requiring entering a password before performing administrative-type actions (unless the password is for sudo - and that is dangerous, see above).

* run a daemon under root that allows making edits to /etc/hostname. Provide an IPC interface to request a change to /etc/hostname; have the daemon check, via a call to a flexible, configurable authorization service, that the caller process has the right to perform a "change /etc/hostname" action (the authorization service might reply yes if, for example, the caller's user belongs to a specific group and verified his password within the last N minutes); and only then make the change on behalf of the unprivileged caller.

The latter seems like a better solution. Maybe over-engineered for managing a one-line config file, but definitely the solution to go with for more complex situations; so we might as well use the general solution in this case too.

The daemon is hostnamed; the flexible authorization service is polkit. See https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ for more details.

Honestly, all these points make me feel sick from an architecture point of view. Why cannot groups be applied to the user instantly? Why doesn't system have regular ways to change 'registry' values (sorry for analogy, but /etc is a standard-defined setting storage; I'm a unix guy, ftr). If the kernel team has good arguments against that, why hostnamed is not named privilege-d and not using some system bus to change anything beyond hostname? Is hostname the only thing with such problem, the only gui-configurable system-wide setting?

While being a formally valid solution, it all seems like waste of simplicity and totally uncontrolled design process.

> Why cannot groups be applied to the user instantly?

Good question! I've wondered about this before too, ought to research it.

> Is hostname the only thing with such problem, the only gui-configurable system-wide setting?

Of course not :) Systemd provides a half-dozen similar daemons for configuring things; hostnamed is probably the simplest one of them, so I was trying to justify why so much engineering went into something that looks so trivial: it's because the approach is generic.

The idea is that a non-systemd system could reimplement some of these daemons (or rather, their dbus interface; you could implement them in one executable if you want) - and the parts of a standard control panel application relevant to your system would just work.

Wait, since when is sudo considered dangerous? Forget the GUI for editing the hostname file, we have much more important things to worry about if that's the case.

He's not saying that sudo is dangerous but that a GUI program running in X11 as root is dangerous. This is because most GUI toolkits aren't hardened against attackes (buffer overflows, badly formed events, etc.) that can all be sent as a non-privileged user/program under X11 to one that's running as root. This means that if someone had an exploit in your browser that let them see X11 events or send them to another window then they could potentially use that to gain root access the moment you went into ANYTHING that ran as root under you X session.

Yes, exactly. I should have been more clear.

"sudo vim /etc/whatever.conf" is perfectly fine.

"sudo gedit /etc/whatever.conf" might give an attacker already on your system a way to gain root.

Then why use a GUI to edit the hostname in the first place? Either use sudo or fix the security issues with Xorg.

If you tell users to edit the file, they will do something stupid like using LibreOffice. Ubuntu wants to be useable without using a terminal.

> Either use sudo

Yes, just keep doing that. I run several Linux boxes with systemd, all of them without hostnamed.

Forcing all your users to use the One True Way on a complicated system usually just means you're ignoring many legitimate use cases. Microsoft still does that on Windows (APIs and ugly registry entries over everything) - and while I cringe everytime I see it, I still recognize that the approach has value for some situations.

Many of the daemons for systemd on the other hand are optional, which I personally find to be great. I can use the ones I need and leave the ones I don't.

As for the GUI: Why use a text file? That might be a good use case for you and me, but a terrible one for someone not used to administrate *NIX systems. Why not allow both? As long as the file-based approach is not neglected, I'm perfectly fine with that.

Reply on news.ycombinator.com