Bug 79539

Summary: 5.3 nfs tasks running and not selected at install time
Product: Base System Reporter: FBSD mailing List <fbsd_user>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description FBSD mailing List 2005-04-04 20:50:07 UTC
I just installed 5.3 production release version from cd mini.iso and did not select nfs server or nfs client during the install but nfs still gets activated. When I issue the ps ax  command I see that nsfiod 0, 1, 2 ,4 is running. This did not happen under 4.x systems. I also get this message in the boot log  "Mounting NFS file systems". Only way to stop the auto spanning of these un-wanted and not needed tasks is to recompile the kernel source with all nfs options commented out.  

Any un-used running tasks is a potential security risk. 

This was reported 1/16/2004 in 5.2 RC2 as Problem Report kern/61438 and somebody lowered its importance so it has never been addressed.  Why have a RC version if problems are not going to be addressed and fixed before becoming a release version.

Fix: 

recompile the default kernal without nfs support and incorperate it into the 5.4 release or find and correct what ever was changed between 4.10 and 5.3 so those nfsiod tasks are not auto spanned at boot time unless nfs client or nfs server enable statements are in rc.conf.
How-To-Repeat: install 5.3 from scratch and answer no the both NFS sysinstall questions and then after install is completed issue ps ax command to see the 4 mfsiod tasks running
Comment 1 Mark Linimon 2005-04-05 03:21:59 UTC
On Mon, 4 Apr 2005, Joe wrote:

> This was reported 1/16/2004 in 5.2 RC2 as Problem Report kern/61438 and
> somebody lowered its importance so it has never been addressed.

There is a myth that setting the priority obligates any developer to
work on any open PR.  In actuality FreeBSD is developed and maintained
almost completely by volunteers and as such no one is really obligated
to work on anything.

> Why have a "RC" version if problems are not going to be addressed
> and fixed before becoming a release version.    

Many problems do indeed get addressed during an RC period.  In particular
the QA cycles for 5.2 and 5.3 fixed dozens if not hundreds of problems.
But if we waited until every single problem was fixed we would never
release any versions whatsoever.

We do the best we can given the available volunteers and beyond that
there is really no guarantee.

mcl
Comment 2 FBSD mailing List 2005-04-05 04:17:52 UTC
On Mon, 4 Apr 2005, Joe wrote:

> This was reported 1/16/2004 in 5.2 RC2 as Problem Report
kern/61438 and
> somebody lowered its importance so it has never been addressed.

There is a myth that setting the priority obligates any developer to
work on any open PR.  In actuality FreeBSD is developed and
maintained
almost completely by volunteers and as such no one is really
obligated
to work on anything.

> Why have a "RC" version if problems are not going to be addressed
> and fixed before becoming a release version.

Many problems do indeed get addressed during an RC period.  In
particular
the QA cycles for 5.2 and 5.3 fixed dozens if not hundreds of
problems.
But if we waited until every single problem was fixed we would never
release any versions whatsoever.

We do the best we can given the available volunteers and beyond that
there is really no guarantee.

mcl
-----Original Message-----
From: Mark Linimon [mailto:linimon@lonesome.com]
Sent: Monday, April 04, 2005 10:22 PM
To: Joe
Cc: freebsd-gnats-submit@FreeBSD.org; freebsd-bugs@FreeBSD.org
Subject: Re: kern/79539: 5.3 nfs tasks running and not selected at
install time
Well thanks for the history lesson, but can it get address and fixed
for the 5.4 release?
Comment 3 Kris Kennaway freebsd_committer freebsd_triage 2005-04-09 01:35:40 UTC
State Changed
From-To: open->closed

As discussed on the mailing list, this is intentional behaviour and is 
not a security risk.  To disable NFS client support the only thing you 
can do is remove it from your kernel and recompile.