From owner-freebsd-hackers Wed Sep 13 10:39:28 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA19095 for hackers-outgoing; Wed, 13 Sep 1995 10:39:28 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA19089 for ; Wed, 13 Sep 1995 10:39:26 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA07708; Wed, 13 Sep 1995 10:37:52 -0700 From: Terry Lambert Message-Id: <199509131737.KAA07708@phaeton.artisoft.com> Subject: Re: smfs To: owensc@enc.edu (Charles Owens) Date: Wed, 13 Sep 1995 10:37:52 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG, leisner@sdsp.mc.xerox.com In-Reply-To: from "Charles Owens" at Sep 13, 95 11:03:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2436 Sender: hackers-owner@FreeBSD.ORG Precedence: bulk > I've been using the regular samba package for a while now and like it > very much. The only problem I see is that for each user connected, a new > smbd process gets spawned with a size ranging from 500K to 1meg. This > limits the number of users I can support. > > For this reason, I'm VERY interested in seeing/helping smfs get ported to > FreeBSD. Are you pursuing this? Anyone else? Any way I can help? Why would porting smbfs (a kernel-level file system UNIX client) help the smbd (a user-level SMB UNIX server) process count? Also: You know that the smbfs "logs in" as a single client into an SMB server (possibly smbd on another box) and thus has only a single credential authenticated, that credential to be used by all UNIX users the kernel funnels through the file system, right? To truly support this, the per process credentials structure would need to be expanded to include SMB authentication credentials so that the authentication of SMB clients was done on the basis of one SMB user per one UNIX user. Then there's still the problem of causing a credential request callback from kernel to user space to support the fact that the UNIX login and the SMB login don't use a unified password database and enforcement mechanism. UNIX doesn't support a broadcast/bradcast-reply mechanism. The closest you can get is requiring the user to run a graphical interface like X and run a process to answer the callbacks and pop up the requester. The alternative is unencrypted UNIX passwords flying over your wire. Or one credential per UNIX box instead of one credential per UNIX user. Which is the same thing as granting world permissions to all UNIX users on a UNIX box for all files accessable under the box's credential. This leads to some "interesting" security anomolies. After 3 years of work on the UnixWare NetWare Client filesystem, there are still problems like this. The next step was adding directory services credentials to each UNIX user. This begs the question of what credentials the processes involved in boot use until networking is up and a Directory Services NDS branch becomes available to use for authentication. Oh, an ugly, ugly problem. If you go to implement this, at least think about the issues involved before just blindly implementing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.