Date: Thu, 29 Aug 1996 10:51:37 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mday@Artisoft.COM (Matt Day) Cc: freebsd-current@FreeBSD.org Subject: Re: SAMBA Message-ID: <199608291751.KAA29043@phaeton.artisoft.com> In-Reply-To: <199608290033.RAA14743@sting.artisoft.com> from "Matt Day" at Aug 28, 96 05:33:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... CIFS information ... ] Thanks for the additional information; I wasn't sure if you would jump in on this or not. You are certainly more up to date on CIFS than any of the rest of us. > If you want to mount Win95 drives from a FreeBSD system, please > don't wait for CIFS - CIFS won't be ready for months, at least. > Instead, port or write ksmbfs for FreeBSD! The ksmbfs kernel module > for Linux (in Samba's contributed section) already provides the > capability to mount SMB volumes from Linux. (Unfortunately, you > can't NFS export stuff mounted by ksmbfs, due to limitations.) > Getting ksmbfs on FreeBSD would also be a great way to help prepare > FreeBSD for CIFS. > > Download ksmbfs from: > ftp://samba.anu.edu.au/pub/samba/contributed/ksmbfs-0.2.4.tgz How do you resolve: 1) It's GPL'ed code 2) It does not allow per-user enforcement of credential mapping The first is not really a kicker if it's distributed as an LKM, and the LKM is not distributed pre-loaded. Its just that you can't sell or even give away the agregate system because of the license conflicts. The second is a serious issue, since it damages the SMB server administrators management authority to have all users from a given UNIX box appear as as a single SMB client. This was my objection to the SMBFS suggestions I have seen in the past. I did an SMBFS for FreeBSD 1.1.5.1 (so it would be a hard port, and it is code Novell/USG claimed they owned because I was a Novell employee when I did it on my own time before Novell bought USL). The credential problem is significant, and I did not solve it in my prototype code. IF FreeBSD supported attaching additional credential information to a session (ie: it had the concept of a session manager, which it applied to normal console logins, as well as to "screen" and "xdm" logins), then it would be possible to implement a method of querying the user asynchronously for the information the kernel needs to establish a seperate connection credential for the user for a given mount. For remote sessions, and for TTY's, where it is impossible to pop up a "dialog" without potentially destroying unrecoverable screen contents, preauthentication would be required. This basically means adding an EAUTH error code to all pathing operations, and handling the error return in all programs which invoke those system/library calls. Then the applications can self-handle querying for authentication without damaging the application context. There is also the posibility of a Window95-style "password cache" in this scenario, the cache being managed by the session manager, and cache unlocking forced at login time along with standard system login. This incidently buys you the ability to have password protected directories and files, since the missing piece for that FS extentionis the ability to query the user for authentication data; same proble, different context. But short of this, porting SMBFS directly is a bad idea, since it damages existing security models on servers we can't do anything about because they come from Microsoft, or AT&T, or IBM, etc., an they don't have source code. There is no way to repair the damage, other than to note it, and have the SMB server administrator react appropriately (which is undefined, since the situation never arises without SMBFS rearing its ugly head). If you intentionally go ahead and damage someone elses security model by making an N:1 mapping of a resource which is, by design, expected to be 1:1 mapped by a single user client machine, be prepared to take on a lot of heat for doing it. This is *exactly* the problem the NUC (NetWare UNIX Client) people at Novell dealt with in UnixWare, NeXTStep, etc., and exactly the issue that caused them the most grief in their 20 man year (5 engineers over 4 years) project to solve the problem unformly and securely. My offer to help work on a session management interface (made in a Usenet posting on SMBFS) still stands; there did not seem to be a lot of interest in resolving the general problem, when a kludge soloution was so close. 8-(. Regards, 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?199608291751.KAA29043>