Now that networkd doesn't run as uid 0 it no longer has access to set the transient hostname via hostnamed without polkit. I also do not see a polkit rule in the systemd tree giving it access so either I'm missing something or setting the hostname from DHCP is broken for everyone. CoreOS currently doesn't ship polkit but we could if needed. Before I go through the trouble of adding it I'd like to know how on earth this is supposed to work. :)
Thanks for the report. This is indeed broken, I need to add the right polit hookups to hostnamed.
Created attachment 104840 [details] set-hostname polkit rule for networkd Here is the polkit file I've added to CoreOS, hadn't had a chance yet to turn it into a proper patch to submit upstream.
That polkit rule looks like the correct solution. Eventually, we can probably avoid the polkit dependency here once we use kdbus, but in the meantime I'd be very happy to merge a patch to ship that polkit rule.
I strongly discourage you from installing rules with systemd. Please see the polkit man-page. Rules are meant exclusively for administrator-control and non-generic system setups. A system should run just fine with an empty /usr/share/polkit-1/rules.d/. I don't have any better solution for this problem, though. So maybe we should document this polkit-rule as workaround in the wiki until we find a real fix. This problem is kind of nasty because we want to allow a non-root user to access APIs that other non-root users cannot. But access-control has always been under control of the API-provider, not of the API-user. Therefore, installing rule files with networkd sounds wrong to me. It's hostnamed that should open the API to a specific set of users. Meh.. we really need a proper solution here.
(In reply to comment #4) > I strongly discourage you from installing rules with systemd. Please see the > polkit man-page. Rules are meant exclusively for administrator-control and > non-generic system setups. A system should run just fine with an empty > /usr/share/polkit-1/rules.d/. > > I don't have any better solution for this problem, though. So maybe we > should document this polkit-rule as workaround in the wiki until we find a > real fix. > > This problem is kind of nasty because we want to allow a non-root user to > access APIs that other non-root users cannot. But access-control has always > been under control of the API-provider, not of the API-user. Therefore, > installing rule files with networkd sounds wrong to me. It's hostnamed that > should open the API to a specific set of users. > > Meh.. we really need a proper solution here. Hmm? All kinds of packages install files in /usr/share/polkit-1/rules.d/, and I think that's totally and OK thing to do. [root@delta systemd]# ls -l /usr/share/polkit-1/rules.d/ total 12 -rw-r--r--. 1 root root 443 12. Okt 2012 11-fedora-kde-policy.rules -rw-r--r--. 1 root root 1016 29. Nov 2013 20-gnome-initial-setup.rules -rw-r--r--. 1 root root 488 3. Mär 13:14 gnome-control-center.rules [root@delta systemd]# rpm -qf /usr/share/polkit-1/rules.d/* kde-settings-20-14.fc20.noarch gnome-initial-setup-3.10.1.1-4.fc20.x86_64 control-center-3.10.3-1.fc20.x86_64 So, am all for adding a patch for this.
> Hmm? All kinds of packages install files in > /usr/share/polkit-1/rules.d/, and I think > that's totally and OK thing to do. That's a weird excuse, but please go ahead. I'm just relying on polkit docs here, which say (polkit(8)): "In particular, applications, mechanisms and general-purpose operating systems must never include any authorization rules." If that rule was never enforced, nor considered valuable, there is no reason to adhere to it.
(In reply to comment #6) > > Hmm? All kinds of packages install files in > > /usr/share/polkit-1/rules.d/, and I think > > that's totally and OK thing to do. > > That's a weird excuse, but please go ahead. I'm just relying on polkit docs > here, which say (polkit(8)): > > "In particular, applications, mechanisms and general-purpose operating > systems must never include any authorization rules." > > If that rule was never enforced, nor considered valuable, there is no reason > to adhere to it. I am a bit puzzled by that. What's the rationale here? I mean this is neither current practice, nor do I get why? I mean, we need some way how we can ship vendor supplied default policies, and I am pretty sure we shouldn't come up with a a third layer of policy to enforce stuff like this. Also, why is there even /usr/share/polkit-1/rules.d/ if it's not for the package vendor to fill with stuff? I guess I should ping davidz about this.
> I am a bit puzzled by that. What's the rationale here? I have no idea. That's why I said go ahead if that's not enforced so far. Honestly, I think installing rule-files with packages is a bit like Android, where you agree to privileges of an application at install time. Placing .rule files in /usr is quite similar. With that in mind, this sounds reasonable to me. But yes, I think we should query Zeuthen first. I'm fine with shipping the .rule file with systemd now. I just stumbled across the man-page and wondered what it is all about (given that my /usr/share/polkit-1/rules.d/ dir is empty).
Fixed in https://github.com/systemd/systemd/pull/4710
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.