Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #94599 > unrolled thread

Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate Elliott Mitchell <ehem+debian@m5p.com> - 2026-10-24 04:00 +0200
    Processed: Re: Bug#1151866: nfs-common: host= setting in nfs.conf  inadaquate "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-10-29 07:30 +0100
    Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate Salvatore Bonaccorso <carnil@debian.org> - 2026-10-29 07:30 +0100
      Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate Elliott Mitchell <ehem+debian@m5p.com> - 2026-10-31 02:30 +0100
    Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate Uwe Kleine-König <ukleinek@debian.org> - 2026-11-04 22:50 +0100

#94599 — Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate

Package: nfs-common
Version: 1:2.8.3-1

The "host=" setting in /etc/nfs.conf isn't fit for the function it needs
to perform.  Of note it doesn't allow binding to multiple addresses.  It
also doesn't allow restricting to binding IPv4-only nor IPv6-only.  In
fact I was unable to get it to restrict IPv6 binding at all.

Multiple addresses is a common configuration.  Disabling IPv4 or IPv6
are also common.

It also appears stopping/starting `/etc/init.d/nfs-kernel-server` appears
to leave old address bindings in place.  If the "host=" setting is added,
then the daemon is restarted it will remain bound to the wildcard
address.

NFS is a service which should be filtered at firewalls, but it should
still be possible to restrict binding as a backup security measure.  I'm
tempted to rate this as pretty high importance.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

[toc] | [next] | [standalone]

#94673 — Processed: Re: Bug#1151866: nfs-common: host= setting in nfs.conf inadaquate

Processing control commands:

> tags -1 +moreinfo
Bug #1151866 [nfs-common] nfs-common: host= setting in nfs.conf inadaquate
Added tag(s) moreinfo.

-- 
1151866: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1151866
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#94674

Control: tags -1 +moreinfo

Hi,

On Fri, Oct 23, 2026 at 06:53:21PM -0700, Elliott Mitchell wrote:
> Package: nfs-common
> Version: 1:2.8.3-1
> 
> The "host=" setting in /etc/nfs.conf isn't fit for the function it needs
> to perform.  Of note it doesn't allow binding to multiple addresses.  It
> also doesn't allow restricting to binding IPv4-only nor IPv6-only.  In
> fact I was unable to get it to restrict IPv6 binding at all.
> 
> Multiple addresses is a common configuration.  Disabling IPv4 or IPv6
> are also common.
> 
> It also appears stopping/starting `/etc/init.d/nfs-kernel-server` appears
> to leave old address bindings in place.  If the "host=" setting is added,
> then the daemon is restarted it will remain bound to the wildcard
> address.
> 
> NFS is a service which should be filtered at firewalls, but it should
> still be possible to restrict binding as a backup security measure.  I'm
> tempted to rate this as pretty high importance.

Thanks for your report. Those are rather questions and issues to bring
to upstream. Can you report them to upstream via the linux-nfs
mailinglist (linux-nfs@vger.kernel.org) and please include as well
both Steve Dickson <steved@redhat.com> directly and this Debian
downstream bugreport, so we can keep track.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#94693

On Thu, Oct 29, 2026 at 07:23:28AM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 +moreinfo
> 
> Hi,
> 
> On Fri, Oct 23, 2026 at 06:53:21PM -0700, Elliott Mitchell wrote:
> > Package: nfs-common
> > Version: 1:2.8.3-1
> > 
> > The "host=" setting in /etc/nfs.conf isn't fit for the function it needs
> > to perform.  Of note it doesn't allow binding to multiple addresses.  It
> > also doesn't allow restricting to binding IPv4-only nor IPv6-only.  In
> > fact I was unable to get it to restrict IPv6 binding at all.
> > 
> > Multiple addresses is a common configuration.  Disabling IPv4 or IPv6
> > are also common.
> > 
> > It also appears stopping/starting `/etc/init.d/nfs-kernel-server` appears
> > to leave old address bindings in place.  If the "host=" setting is added,
> > then the daemon is restarted it will remain bound to the wildcard
> > address.
> > 
> > NFS is a service which should be filtered at firewalls, but it should
> > still be possible to restrict binding as a backup security measure.  I'm
> > tempted to rate this as pretty high importance.
> 
> Thanks for your report. Those are rather questions and issues to bring
> to upstream. Can you report them to upstream via the linux-nfs
> mailinglist (linux-nfs@vger.kernel.org) and please include as well
> both Steve Dickson <steved@redhat.com> directly and this Debian
> downstream bugreport, so we can keep track.

I thought that was specifically the duty of the maintainer.  In
particular this often needs a subscription to a mailing list, which the
maintainer will have.  Whereas asking for users to subscribe to yet
another list for every bug is a major problem.

I guess this is likely actually two bugs.  First, running
`/etc/init.d/nfs-kernel-server stop` fails to close the listening socket.
Second is only being able to specify a single-IPv4 address for the host
setting.

I should add it could be useful to bind different ports on different
addresses.  One might even desire a port on the wildcard address, then
different ports on various interfaces.  Then there is the issue of being
unable to disable IPv4 (likely IPv6 too).


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

[toc] | [prev] | [next] | [standalone]

#94780

[Multipart message — attachments visible in raw view] — view raw

Hello Elliott,

On Fri, Oct 30, 2026 at 06:03:47PM -0700, Elliott Mitchell wrote:
> On Thu, Oct 29, 2026 at 07:23:28AM +0100, Salvatore Bonaccorso wrote:
> > Thanks for your report. Those are rather questions and issues to bring
> > to upstream. Can you report them to upstream via the linux-nfs
> > mailinglist (linux-nfs@vger.kernel.org) and please include as well
> > both Steve Dickson <steved@redhat.com> directly and this Debian
> > downstream bugreport, so we can keep track.
> 
> I thought that was specifically the duty of the maintainer.  In
> particular this often needs a subscription to a mailing list, which the
> maintainer will have.  Whereas asking for users to subscribe to yet
> another list for every bug is a major problem.

Playing man in the middle for every bug is the matching problem for the
case where the maintainer does the forwarding. So given that you have
the main interest in getting this bug fixed (as it's quite niche and
doesn't affect most Debian users) the direct communication between you
and upstream is IMO the best way forward. Ideally keep
1151866@bugs.debian.org on Cc: to keep the bug updated.

Also note that for vger.kernel.org lists you don't need to subscribe to
post and the kernel folks is usually good at replying correctly there.
So there shouldn't be a need for a subscription.

Best regards
Uwe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web