Bug 81626 - networkd lacks access to hostnamed
Summary: networkd lacks access to hostnamed
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Tom Gundersen
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-22 01:27 UTC by mike@marineau.org
Modified: 2016-11-24 00:59 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
set-hostname polkit rule for networkd (217 bytes, text/plain)
2014-08-18 18:13 UTC, mike@marineau.org
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mike@marineau.org 2014-07-22 01:27:46 UTC
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. :)
Comment 1 Tom Gundersen 2014-08-18 17:57:19 UTC
Thanks for the report. This is indeed broken, I need to add the right polit hookups to hostnamed.
Comment 2 mike@marineau.org 2014-08-18 18:13:33 UTC
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.
Comment 3 Tom Gundersen 2014-08-18 21:52:46 UTC
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.
Comment 4 David Herrmann 2014-08-19 17:37:01 UTC
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.
Comment 5 Lennart Poettering 2014-08-19 19:10:03 UTC
(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.
Comment 6 David Herrmann 2014-08-20 10:07:36 UTC
> 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.
Comment 7 Lennart Poettering 2014-08-20 13:06:59 UTC
(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.
Comment 8 David Herrmann 2014-08-20 13:53:09 UTC
> 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).
Comment 9 Lennart Poettering 2016-11-24 00:59:11 UTC
Fixed in https://github.com/systemd/systemd/pull/4710


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.