Bug 975060

Summary: [RFE] Firewalld does not ship with rules for rpcbind / legacy nfs
Product: [Fedora] Fedora Reporter: Jiri Popelka <jpopelka>
Component: firewalldAssignee: Eric Garver <egarver>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: edgar.hoch, jonrysh, jpopelka, nobody, pahan, rcyriac, rdieter, samuel-rhbugs, steved, twoerner
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-10 14:57:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
An example systemd solution to enabling an easy legacy nfs firewalld sevice. (from John Huston)
none
generic rpcbind rule generator for firewalld none

Description Jiri Popelka 2013-06-17 14:27:32 UTC
Created attachment 762040 [details]
An example systemd solution to enabling an easy legacy nfs firewalld sevice. (from  John Huston)

+++ This bug was initially created as a clone of Bug #970126 +++

Description of problem:
firewalld in comes with a number of pre-defined services that users can enable if they wish to make use of that service. The ruleset for the NFS service is currently insufficient in that it only enables a strictly NFS 4.0 environment.

In some cases, even NFS 4.0 clients need extra ports enabled to be able to efficiently make use of the server (mount type heuristics may require port 111, rpcbind, to be open as well.)

Steps to Reproduce:
1. Open firewall-config and enable NFS.
2. Enable the NFS daemon.
3. Attempt to connect with NFS2 or NFS3 clients.

Actual results:

Clients are unable to connect.

Expected results:

Clients should be able to connect with NFS 2, 3 and 4.

Additional info:

This is tricky because I don't know if firewalld allows for dynamic configurations of firewall rules based on rpcbind assignments.

One solution would be to write something that generates the firewall service on-boot, after nfs and all related sub-services have started.

That way, the script can generate a "static" firewall rule that firewalld knows how to work with.

I wrote a quick p.o.c. for this type of startup script, attached below.

Comment 1 Jiri Popelka 2013-06-17 14:30:21 UTC
*** Bug 815645 has been marked as a duplicate of this bug. ***

Comment 2 John Snow 2013-06-17 14:36:02 UTC
It's difficult to know what ports the rpcbind services will want when they boot, but firewalld expects static, unchanging rule definitions in the XML files.

So for each service you care about, you /could/ plug in a script that scrapes rpcinfo and generates an xml and then have firewalld refresh, but that seems costly.

A real solution would (possibly) involve allowing rpcbind some callback mechanisms to generate new rule files as it needs to as services come up, and being able to either inform firewalld that a single service xml has been generated / modified, or ...

Just adding rpcbind support directly into firewalld's reading of conf files -- or some other generic plugin mechanism to allow firewalld to obtain at runtime the correct port information (from scripts or otherwise.)

At the very least, users who are having issues and want a quick-fix can use the systemd hack attached.

I also wrote a more generic one-per-rpcbind-service mechanism, which people might find useful for things like ypserv and ypbind as well.

Comment 3 John Snow 2013-06-17 14:38:00 UTC
Created attachment 762045 [details]
generic rpcbind rule generator for firewalld

Comment 5 Eric Garver 2018-08-10 14:57:35 UTC
This was fixed a long time ago. firewalld ships with services; mountd, rpc-bind, nfs, nfs3

Not adding Fixed In Version because it was so long ago.