Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 1996 13:11:44 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        PLAZAS_CHRISTIAN@mercury.csg.peachnet.edu (Christian)
Cc:        questions@FreeBSD.ORG
Subject:   Re: NCPFS for FreeBSD??
Message-ID:  <199603062011.NAA11715@phaeton.artisoft.com>
In-Reply-To: <6659BB0F36@mercury.csg.peachnet.edu> from "Christian" at Mar 6, 96 10:26:24 am

next in thread | previous in thread | raw e-mail | index | archive | help
>     I am wondering if there are any plans to port Linux's NCPFS to 
> FreeBSD?  I could put this to very good use if it was available 
> for FreeBSD.  

I have no immediate plans.  The problems I see is that each user
must authenticate individually to the Novell server, or there is
no way to enforce intra-system security on a commonly mounted
NetWare file system.

Novell solved this (I was involved in the code review) by having
the ability to pop up an authentication requester as a result of
a kernel event.  This made a lot of assumptions about how the
system was being used; in particular, it assumed the user was on
the console.

It also required integration of the NDS authentication mechanism
into the UNIX login facility so as to cause the credentials to be
the same per process.

Basically, NetWare servers store credentials on a per connection
basis, not a per session basis, so it is impossible to have one
connection and multiple sessions with different credentials on
the NetWare server.

Without the NDS hooks, it is impossible to proxy UNIX credentials
into uniqueNetWare credentials per UNIX user on a single UNIX
machine.

That is, if Bob mounts /NetWare and can write there, then using
the NCPFS implementation in Linux, Biff can do the same thing,
even if Biff is not an allowed NetWare user.

This is exactly the same massive security problem that the SMBFS
LANManager clinet FS poses.

It's acceptable only if you limit the allowable users on the
system to exactly *one* user coming in through an authentication
via login... that is, specifically limit the usability of the
system as a desktop FS.


I have been toying with several ideas to "fix" this, but they all
require reengineering the mount code (going radically further in
the direction I've already headed there) and utilizing POSIX "//x/"
semantics on a formal seperation of hierarchy from mount point
assignment.  This is, of course, possible, given some other pieces
I haven't talked about yet for credential callback, but it is far
from simple.


If you are willing to accept the security risks, feel free to do the
port.

> For those that don't know NCPFS is a program that 
> lets linux machines mount Novell Netware server volumes, print to 
> Netware print queues and spool netware print queues to the Linux 
> printing system.

The print services, at a bare minimum, are a useful utiliy and should
be ported.  The FS mounting is extremely questionable for the reasons
outlined above.

> The latest versions of this utility  also let you export these
> mounted Netware Volumes as NFS filesystems.

This is just plain bad.  It takes no notice of the coherency problems
cause by cache interaction on the two systems.  This is *precisely*
why there needs to be a mechanism to desinate local vs. remote in FS
type flag bits (and there *is* such a mechanism) and is *precisely*
why we do not allow reexport of NFS file system that have been NFS
mounted from another host.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603062011.NAA11715>