Bug 975060 - [RFE] Firewalld does not ship with rules for rpcbind / legacy nfs
Summary: [RFE] Firewalld does not ship with rules for rpcbind / legacy nfs
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Eric Garver
QA Contact: Fedora Extras Quality Assurance
: 815645 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-17 14:27 UTC by Jiri Popelka
Modified: 2018-08-10 14:57 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2018-08-10 14:57:35 UTC
Type: Bug

Attachments (Terms of Use)
An example systemd solution to enabling an easy legacy nfs firewalld sevice. (from John Huston) (1.56 KB, text/plain)
2013-06-17 14:27 UTC, Jiri Popelka
no flags Details
generic rpcbind rule generator for firewalld (2.21 KB, text/plain)
2013-06-17 14:38 UTC, John Snow
no flags Details

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.

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