Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!bofh.dot!in-news.erinet.com!bug.rahul.net!rahul.net!a2i!ddsw1!news.mcs.net!not-for-mail From: les@MCS.COM (Leslie Mikesell) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD vs. Linux Date: 4 Jun 1996 16:33:18 -0500 Organization: /usr/lib/news/organi[sz]ation Lines: 69 Message-ID: <4p2a2u$m99@Mercury.mcs.com> References: <318FA7CB.8D8@hkstar.com> <4o584s$n9l@uriah.heep.sax.de> <4ogkn2$20b@Mercury.mcs.com> <31B0E3BD.60B31603@lambert.org> NNTP-Posting-Host: mercury.mcs.com In article <31B0E3BD.60B31603@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >] Yes, but that makes the more interesting issue whether or not it >] may be useful to allow these users and pseudo-users access to >] certain remote files even though the remote filesystem doesn't >] maintain a concept of multiple users. (That is, might you want >] to use a network to actually share access?). > >SMB servers and NetWare servers *do* have a concept of user; >they just don't have the concept seperate from connection. Some do, some don't (WFWG, Win95 don't know about file ownership). >This is an implementation issue for an SMBFS, and is trivial to >address. [...] >This is because UNIX credentials are associated with sessions, >and a session ID is synonymous with a process group leader, >and the credentials are associated with the proc struct instead >of being use in common for all processes with a given user ID. None of which makes any sense to the sorts of things you are likely to want to do to a remote machine, like deliver mail proxying for many users, or full backups. >NFS uses this credential model by having the client user on >a given host have to run on a "trusted" host to allow the >kernel to proxy the user credentials to the server by inserting >them into the packets that go acress the wire. Which means, of course, that root on the client machine can pretend to be anyone on the shared area of the server. >Because SMB and NetWare servers don't have the concept of >"trusted host", a proxy approach won't work. The conversion >of credentials must take place on the client system. Which means, in the case of unix as a client, that root is equally responsible for maintaining appropriate access levels, perhaps by protecting the mount points with the usual methods. >This is easier to think of if you think of each login session >on a UNIX box as an authentication instance (or "client"). Only if you want the security to map to unix models. In fact it tends to be difficult to set up the network model that is needed for most office work under unix - that is, a number of groups who need read access to one set of files, read/write to another set, where some individuals are members of many groups and others should be restricted to their own. Some versions of unix will let you be in multiple groups at once, but how are you going to map this into the SMB model? >This is a harder problem to solve. People seem to be willing >to sacrifice security rather than addressing this issue; in >particular, the Linux SMBFS does exactly that: sacrifices >user-level security for a marginal improvement in convenience. Or, perhaps if they have no particular need for additional security (i.e. everyone on the net would be members of the group with access anyway). Or perhaps they use applications which provide their own security mechanisms, like MS access with encrypted data files. In my opinion this is the correct approach since it requires no particular trust in either the network or operating system. (Although I don't know how well access does it...). Les Mikesell les@mcs.com