Bug 1204226 - Figure out how to make dhclient optional
Summary: Figure out how to make dhclient optional
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-20 16:21 UTC by Colin Walters
Modified: 2017-01-19 09:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-19 09:04:47 UTC
Type: Bug


Attachments (Terms of Use)

Description Colin Walters 2015-03-20 16:21:22 UTC
Now that dhcp=internal exists, it'd be nice to make dhclient an optional install.

Possibly this is too painful at a packaging level, and we should wait until dhcp=internal can be the default?

Comment 1 Tomáš Hozza 2015-03-23 07:41:15 UTC
Maybe NetworkManager could use the new RPM weak dependencies for dhclient...

http://www.rpm.org/wiki/PackagerDocs/Dependencies#Weakdependencies

Comment 2 Jan Kurik 2015-07-15 14:22:54 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 3 Fedora Admin XMLRPC Client 2015-08-18 15:00:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin XMLRPC Client 2015-08-18 15:01:02 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Colin Walters 2016-10-12 15:06:05 UTC
So, any objections if I just delete the Requires: dhclient in rawhide?

Comment 7 Matthew Miller 2016-10-12 17:44:29 UTC
FWIW, I've been using my laptop with dhcp=internal for a good while now and have never had to give it a second thought.

What does NetworkManager do if dhclient isn't installed? Does it use dhcp=internal automatically?

Comment 8 Gerald Cox 2016-10-12 18:25:45 UTC
(In reply to Matthew Miller from comment #7)
> FWIW, I've been using my laptop with dhcp=internal for a good while now and
> have never had to give it a second thought.
> 
> What does NetworkManager do if dhclient isn't installed? Does it use
> dhcp=internal automatically?
 
Apparently...

dhcp
This key sets up what DHCP client NetworkManager will use. Allowed values are dhclient, dhcpcd, and internal. 

The dhclient and dhcpcd options require the indicated clients to be installed. The internal option uses a built-in DHCP client which is not currently as            featureful as the external clients.

If this key is missing, available DHCP clients are looked for in this order: dhclient, dhcpcd, internal.

Comment 9 Gerald Cox 2016-10-12 18:41:07 UTC
(In reply to Colin Walters from comment #6)
> So, any objections if I just delete the Requires: dhclient in rawhide?

So, basically you're talking about removing the dependency, correct?  Not, changing the NetworkManager.conf file to dhcp=internal.

The reason I'm asking is that in Comment 8 I copied what the man page says, which is:  The internal option uses a built-in DHCP client which is not currently as            featureful as the external clients.

That being the case, if someone decides to install it, they shouldn't have to worry about modifying the NetworkManager.conf - especially since if dhclient or dhcpcd are NOT installed, it will automatically default to internal.

Comment 10 Colin Walters 2016-10-12 18:53:53 UTC
Yeah, I think the implementation of this change would be to just remove the Requires, allowing people who e.g. do somethin with dhclient script hooks to still install it.

Comment 11 Stephen Gallagher 2016-10-12 19:07:29 UTC
With the recent shift to having repodata created on Fedora systems, we should now in theory be able to support rich deps in Requires.


I think we could use the if/else format of rich deps to hack around this:

Requires: (filesystem if fedora-release-atomic else dhclient)

(picking "filesystem" as something we can guarantee will already be on the system so we don't pull in something new)

CCing Kevin Fenzi to let us know if the rich deps are expected to be safe now.

Comment 12 Kevin Fenzi 2016-10-12 19:41:19 UTC
Nope. rich deps are still completely no go. 

In order for them to work, mash would need to switch to createrepo_c or we would need to stop using mash and switch to signed koji repos using createrepo_c

createrepo (which mash uses) uses yum and it errors on rich deps. It ignores weak deps and they just go though to the repo.

Comment 13 Thomas Haller 2016-10-14 07:38:40 UTC
Overall, I think dhcp=internal is still not yet ready for prime-time, so maybe the default on Fedora should continue to be dhcp=dhclient (dhcp=dhcpcd is not even available on Fedora).


Supposing we want to change the default, we could do that by changing the default setting to dhcp=internal. To avoid upgrade issues, we could add a new package "NetworkManager-config-dhcp-dhclient" that Obsoletes: NetworkManager < %{version}, so that it's installed on update.

Only the new package would have a dependency on dhclient, and it installs a config file /usr/lib/NetworkManager/00-dhcp-dhclient.conf with

[main]
dhcp=dhclient

Comment 14 Thomas Haller 2016-10-14 09:39:29 UTC
how about https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=th/no-dhclient-default-rh1204226

- dhcp: make default dhcp plugin configurable at compile-time
- contrib/rpm: add NetworkManager-config-dhcp-dhclient package

Comment 15 Pavel Šimerda (pavlix) 2016-10-14 12:10:55 UTC
(In reply to Thomas Haller from comment #13)
> (dhcp=dhcpcd is not even available on Fedora).

Why is that?

FYI: http://koji.fedoraproject.org/koji/packageinfo?packageID=21994

Comment 16 Thomas Haller 2016-10-14 12:39:37 UTC
(In reply to Pavel Šimerda (pavlix) from comment #15)
> (In reply to Thomas Haller from comment #13)
> > (dhcp=dhcpcd is not even available on Fedora).
> 
> Why is that?

ah. Ok, I was not aware of that. Strangely, `dnf install dhcpcd` does not find any package for me (F24).

Anyway, NetworkManager is not build with support for dhcpcd (though maybe it should then).

Comment 17 Stephen Gallagher 2016-10-14 12:52:55 UTC
(In reply to Thomas Haller from comment #16)
> (In reply to Pavel Šimerda (pavlix) from comment #15)
> > (In reply to Thomas Haller from comment #13)
> > > (dhcp=dhcpcd is not even available on Fedora).
> > 
> > Why is that?
> 
> ah. Ok, I was not aware of that. Strangely, `dnf install dhcpcd` does not
> find any package for me (F24).
> 
> Anyway, NetworkManager is not build with support for dhcpcd (though maybe it
> should then).

That's because dhcpd exists only in updates-testing on F24. Not sure why it was missed previously.

(In reply to Thomas Haller from comment #13)
> Supposing we want to change the default, we could do that by changing the
> default setting to dhcp=internal. To avoid upgrade issues, we could add a
> new package "NetworkManager-config-dhcp-dhclient" that Obsoletes:
> NetworkManager < %{version}, so that it's installed on update.

I don't think we want to switch anyone away from a working default without their consent. I think it's acceptable to just generate a .rpmnew file and let them decide whether to change.

Comment 18 Colin Walters 2016-10-14 13:24:36 UTC
(In reply to Thomas Haller from comment #13)
> Overall, I think dhcp=internal is still not yet ready for prime-time

Why?

Comment 19 Thomas Haller 2016-10-14 13:35:46 UTC
(In reply to Stephen Gallagher from comment #17)

> (In reply to Thomas Haller from comment #13)
> > Supposing we want to change the default, we could do that by changing the
> > default setting to dhcp=internal. To avoid upgrade issues, we could add a
> > new package "NetworkManager-config-dhcp-dhclient" that Obsoletes:
> > NetworkManager < %{version}, so that it's installed on update.
> 
> I don't think we want to switch anyone away from a working default without
> their consent. I think it's acceptable to just generate a .rpmnew file and
> let them decide whether to change.

I don' think it would. In which scenario do you see that happen?
- Note that the config file is non-user-configuration in /usr/lib/NM/conf.d. User-configuration from /etc/NM has higher priority and overwrites the setting.

(In reply to Colin Walters from comment #18)
> (In reply to Thomas Haller from comment #13)
> > Overall, I think dhcp=internal is still not yet ready for prime-time
> 
> Why?

because the dhcp code is a static "library" that is not separately maintained. We take large parts of systemd's source tree and import it in NetworkManager. Also, it's network-facing C code in NetworkManager (which still has far too many previledges).

I would feel better if we would sandbox the dhcp code and if it would be a separate package (maintainability wise).

Comment 20 Colin Walters 2016-10-16 13:18:12 UTC
(In reply to Thomas Haller from comment #19)

> because the dhcp code is a static "library" that is not separately
> maintained. We take large parts of systemd's source tree and import it in
> NetworkManager. Also, it's network-facing C code in NetworkManager (which
> still has far too many previledges).
> 
> I would feel better if we would sandbox the dhcp code and if it would be a
> separate package (maintainability wise).

The sandboxing seems somewhat of a distinct thread from having it be actually a shared library.

And for whatever reason, it sits on a lot of RSS (15MB in this CentOS7 AH instance).

The dhcp client code is basically a textbook example of a mature product; it's unlikely to change much in the future I'd say.  The ISC seems to mostly be working on a new DHCP server (Kea) now for whatever reasons.

Whereas systemd is evolving rapidly, and they're generally pushing harder to use more security features like seccomp and namespaces for their internal services, so it seems to me a lot more likely that the systemd code would be usable in a separate process with a known seccomp policy etc.

I guess long term, the most maintainable thing would be if networkd could be spun up in a do-DHCP-once mode or so?

Comment 21 Thomas Haller 2016-10-23 13:09:07 UTC
(In reply to Colin Walters from comment #20)
> (In reply to Thomas Haller from comment #19)

> The sandboxing seems somewhat of a distinct thread from having it be
> actually a shared library.

they are separate issues, but both could help making it less likely to exploit NetworkManager via malicious DHCP .
-- a separate library would help as it might get more review/usage/coverage/testing.  


> Whereas systemd is evolving rapidly, and they're generally pushing harder to
> use more security features like seccomp and namespaces for their internal
> services, so it seems to me a lot more likely that the systemd code would be
> usable in a separate process with a known seccomp policy etc.

the current "systemd code" as we use it is a static library. Well, not even a library, just copy&paste of the source-tree. It doesn't benefit from seccomp, namespaces etc. until NetworkManager implements some form of sandboxing on it's own.

> I guess long term, the most maintainable thing would be if networkd could be
> spun up in a do-DHCP-once mode or so?

IIUC you suggest replacing the external dhclient process with an external systemd-dhcp... well sure, that sounds great. But that is not what the current "internal" client is. Also it's rather unlikely that systemd implements such an external tool (with public API) any time soon.
Such an external system-dhcp wouldn't even have to replace the "internal" client. Instead, it could be an additional plugin along dhclient,dhcpcd,internal.

The internal client exists now, it just lacks sandboxing today.
A separate systemd-dhcp (service) doesn't even exist yet.

Comment 23 Thomas Haller 2016-11-04 11:36:49 UTC
lrintel didn't like the misuse of the packagement system by adding the NetworkManger-config-dhcp-dhclient package.

That latter commit got reverted, instead we just dropped the dependency:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9bd0ea79546965316663ee74f92e265183994234


The default-value for the "dhcp" configuration is still "dhclient" on Fedora. But NM is graceful in case dhclient is not installed. So, if you don't explicitly configure "dhcp", dhclient will be preferred (if available), otherwise we fallback to "internal".


I still think for now Fedora flavors that install NetworkManager should also install dhclient. Thus, a user by default continues to use dhclient, which seems safer due to the privilege separation.
But now a user can just remove dhclient package and it will all work.


This change is soon hitting Fedora rawhide.

Comment 24 Thomas Haller 2017-01-19 09:04:47 UTC
closing, as the change is in rawhide already.


Note You need to log in before you can comment on or make changes to this bug.