From owner-freebsd-hackers Wed Sep 13 16:42:50 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA00873 for hackers-outgoing; Wed, 13 Sep 1995 16:42:50 -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 QAA00867 for ; Wed, 13 Sep 1995 16:42:49 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA08418; Wed, 13 Sep 1995 16:34:48 -0700 From: Terry Lambert Message-Id: <199509132334.QAA08418@phaeton.artisoft.com> Subject: Re: smfs To: noses@oink.rhein.de (Noses) Date: Wed, 13 Sep 1995 16:34:48 -0700 (MST) Cc: gryphon@healer.com, owensc@enc.edu, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, leisner@sdsp.mc.xerox.com In-Reply-To: <199509132211.AAA13708@oink.rhein.de> from "Noses" at Sep 14, 95 00:11:43 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: 3017 Sender: hackers-owner@FreeBSD.ORG Precedence: bulk > > On Wed, 13 Sep 1995, Terry Lambert wrote: > > > 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? > > That sounds a bit sloppy; you could as well pass on the users' credentials. Really? Say 'bob' is logged into a UNIX box. He cd's to the mounted smbfs partition. What exactly are 'bob''s user credentials tanslated into SMB credentials? Hos does the file system map the uid/gid par for the request into SMB credentials without asking 'bob' to login? Note that the server won't take my word for "this is actually bob and I authenticated him so you can just trust me and not as him to authenticate himself". Sloppy or not, it's the only option. > > Since PC's do not normally implement user-level security, such cannot > > be reasolable implemented without maintaining all the security information > > on the unix side of the transaction. > > I love it when people are talking about PCs in general - I guess a PC > running FreeBSD DOES know about the "unix side of a transaction". But > a number of other operating systems aren't that blind either (e.g. Win NT, > Win 95 (getting it's user database from a Netware server) or even OS/2). I think you misunderstood him. If I have to resolve the credentials on my side of the wire before pushing the request to the server ("here is my connection and session ID that I got when I gave you my username and password from this machine before") then I must establish a connection in the first place and fabricate a session ID (perfectly legal; session ID's are client conveniences only). NFS deals with this by pushing the credential resolution to the server using "my machine has permission to access your file system, as long as your machine enforces access based on the ID's that you trust my machine to provide to your machine on the basis of requests originating in my machines kernel". Basically "here are my preauthenticated credentials, trust them no matter what connection I use". It is the difference between authenticating to the server ("client/server": the SMB model) and authenticating to the network ("peer-server": the NFS model). The idea of authenticating to the network is what pushed the develeopement of NDS (Novell Directory Services) in the first place. I see no analog to NIS or NDS in SMB that will allow me to request the server proxy pre-authenticated credentials on behalf of a multiuser box with local trusted authentication. If you can provide one, then the problem is on the way to being solved; however, this will be a difficult task if the server we are talking about is an NT or WFWG or Samba server, since the wire protocol has no concept of proxy resoloution. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.