Bug 10642 - exports(5) mentions KERBNFS but that's not in LINT
Summary: exports(5) mentions KERBNFS but that's not in LINT
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 3.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Sheldon Hearn
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1999-03-17 21:10 UTC by Stefan Eggers
Modified: 2000-08-11 14:16 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Eggers 1999-03-17 21:10:01 UTC
	exports(5) mentions a kernel option KERBNFS (it really exists)
but this options is not even mentioned in a comment in LINT.  I think
it would be a good idea to add a line "options KERBNFS" to LINT with a
small comment to what it does as that way it gets a bit more attention
and maybe more people make use of it.
Comment 1 k 2000-08-09 21:32:56 UTC
Hi while poking around among the PRs I found this PR.

The option is called NFSKERB _but_,

I found in src/sys/nfs/nfs_socket.c from rev 1.8 that
this option is unimplemented and should therefore not be 
visible in LINT.

==== src/sys/nfs/nfs_socket.c ===
1297: #ifdef NFSKERB
1298:                        XXX
1299: #endif

Using this option would make the kernel not compile.



Doug, you intorduced the code in question.
Do you this this ever will be implemented?

If not I think it should be removed along with the reference 
in exports(5).

Thanks
Johan K
Comment 2 Doug Rabson 2000-08-10 09:24:57 UTC
On Wed, 9 Aug 2000, Johan Karlsson wrote:

> 
> Hi while poking around among the PRs I found this PR.
> 
> The option is called NFSKERB _but_,
> 
> I found in src/sys/nfs/nfs_socket.c from rev 1.8 that
> this option is unimplemented and should therefore not be 
> visible in LINT.
> 
> ==== src/sys/nfs/nfs_socket.c ===
> 1297: #ifdef NFSKERB
> 1298:                        XXX
> 1299: #endif
> 
> Using this option would make the kernel not compile.
> 
> 
> 
> Doug, you intorduced the code in question.
> Do you this this ever will be implemented?
> 
> If not I think it should be removed along with the reference 
> in exports(5).

That is a marker to point out code which was removed to allow the code in
question to be exported. It shouldn't be removed (unless all of the
NFSKERB code is being removed) since it needs to be replaced with an
appropriate call to an encryption routine.

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 20 8348 3944
Comment 3 k 2000-08-10 12:20:53 UTC
At Thu, 10 Aug 2000 09:24:57 BST, Doug Rabson wrote:
> On Wed, 9 Aug 2000, Johan Karlsson wrote:
> > ==== src/sys/nfs/nfs_socket.c ===
> > 1297: #ifdef NFSKERB
> > 1298:                        XXX
> > 1299: #endif
> > 
> > Using this option would make the kernel not compile.
> > 
> > If not I think it should be removed along with the reference 
> > in exports(5).
> 
> That is a marker to point out code which was removed to allow the code in
> question to be exported. It shouldn't be removed (unless all of the
> NFSKERB code is being removed) since it needs to be replaced with an
> appropriate call to an encryption routine.
> 

Ok, thanks for the explanation.

What do you think about removing the reference in exports(5) or at least 
adding something like

"Using this option will make the kernel not compile, if one do not also 
take care of adding calls to the appropriate kerberos encryption routins 
in the NFS source."


/Johan K
Comment 4 Doug Rabson 2000-08-11 09:25:54 UTC
On Thu, 10 Aug 2000, Johan Karlsson wrote:

> At Thu, 10 Aug 2000 09:24:57 BST, Doug Rabson wrote:
> > On Wed, 9 Aug 2000, Johan Karlsson wrote:
> > > ==== src/sys/nfs/nfs_socket.c ===
> > > 1297: #ifdef NFSKERB
> > > 1298:                        XXX
> > > 1299: #endif
> > > 
> > > Using this option would make the kernel not compile.
> > > 
> > > If not I think it should be removed along with the reference 
> > > in exports(5).
> > 
> > That is a marker to point out code which was removed to allow the code in
> > question to be exported. It shouldn't be removed (unless all of the
> > NFSKERB code is being removed) since it needs to be replaced with an
> > appropriate call to an encryption routine.
> > 
> 
> Ok, thanks for the explanation.
> 
> What do you think about removing the reference in exports(5) or at least 
> adding something like
> 
> "Using this option will make the kernel not compile, if one do not also 
> take care of adding calls to the appropriate kerberos encryption routins 
> in the NFS source."

That sounds about right.

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 20 8348 3944
Comment 5 Sheldon Hearn 2000-08-11 11:15:17 UTC
On Fri, 11 Aug 2000 11:12:05 +0200, Johan Karlsson wrote:

> +Using this option will make the kernel not compile, if one do not also 
> +take care of adding calls to the appropriate Kerberos encryption routines 
> +in the NFS source.

Rather this, which addresses the grammar and the line breaking style:

The use of this option will prevent the kernel from compiling
unless calls to the appropriate Kerberos encryption routines
are provided in the NFS source.

I wonder whether it'd be a good idea to provide paths to the affected
source files?

Ciao,
Sheldon.
Comment 6 k 2000-08-11 12:37:21 UTC
At Fri, 11 Aug 2000 12:15:17 +0200, Sheldon Hearn wrote:
> I wonder whether it'd be a good idea to provide paths to the affected
> source files?

The files using the option are:
sys/nfs/nfs_nqlease.c
sys/nfs/nfs_socket.c
sys/nfs/nfs_syscalls.c
sys/nfs/rpcv2.h
sbin/mount_nfs/mount_nfs.c
sbin/nfsd/nfsd.c

where implementation is missing in:
sys/nfs/nfs_socket.c
sys/nfs/nfs_syscalls.c
sys/nfs/rpcv2.h


However, since sbin/munt_nfs and sbin/nfsd uses the option
they will also need to be recompiled.

/Johan K
Comment 7 Sheldon Hearn 2000-08-11 13:33:28 UTC
On Fri, 11 Aug 2000 04:40:03 MST, Johan Karlsson wrote:

>  However, since sbin/munt_nfs and sbin/nfsd uses the option
>  they will also need to be recompiled.

Hmmm, probably just to use the generic text, then.

Ciao,
Sheldon.
Comment 8 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-11 13:55:15 UTC
Responsible Changed
From-To: freebsd-bugs->sheldonh

I'll take this one. 
Comment 9 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-11 14:13:44 UTC
State Changed
From-To: open->closed

Explanation added in both HEAD and RELENG_4.