Date: Wed, 13 Sep 1995 12:58:46 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: owensc@enc.edu, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, leisner@sdsp.mc.xerox.com Subject: Re: smfs Message-ID: <199509131958.MAA08030@phaeton.artisoft.com> In-Reply-To: <199509131909.MAA04080@rah.star-gate.com> from "Amancio Hasty Jr." at Sep 13, 95 12:09:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Curious , could a kerberos like authentication help with the > smbs authentication problem? Changing the UNIX authentication to be identical to the SMB authentication would fix the problem. Changing the SMB authentication to be identical to the UNIX authentication would fix the problem. Setting up a translation mechanism so that SMB credentials could be automatically translated into UNIX credentials would fix the problem (but would compromise UNIX security, since you would need to use SMB credentials for UNIX logins). Setting up a translation mechanism so that UNIX credentials could be automatically translated into SMB credentials would fix the problem (but would require a rewrite at the SMB server level, since SMB server authentication mechanisms are only exported at the SMB login interface and it would be impossible to verify them otherwise). The only other soloution, as already mentioned, is to provide some method of asynchronously querying the user for their SMB credentials when they cross the mount point into an SMB filesystem on a lookup. I suppose you could provide the equivalent of a "net use" command for use in user space, and deny the lookup until such time as that had occurred. This would treat each login instance as a "machine instance". Since you can't have password database unification in this scheme, you either have to leave passwords lying around or the user has to authenticate twice (one to UNIX to get logeed into his "machine" and once to the SMB credential holder in the kernel. To account for SUID and other activity, you'd have to tag the credential to the standard UNIX per process/group credential inheritance mechanism, which would mean expanding the credential structure in any case. This would still leave you hanging in the wind for, for instance, storage of score and data files for SUID/SGID games, etc. on SMB volumes. Almost any way you look at it, it amounts to modifying the UNIX credential instances so that an instance is shared between all processes that are authenticated as a particular user. This is necessary because of the xterm SUID phenomenon, where a program needs to do something on a user's behalf as a credential with a different identity from the base user, then return itself or a subprocess following a fork to the base user identitty. Consider a Sybase database on an SMBFS volume, or consider multiple xterms on a single login "session". The UNIX credential model is near to breaking in many cases, and in any case where a potential alias exists or is created as a result of an action of the original alias. In the case of an SUID 'bob' program run by 'joe', the 'SMB joe' credential doesn't want to be inherited by the 'bob' process. In the case of an SUID 'root' nee SUID 'joe' program run by 'joe' (like our xterm example), the 'SMB joe' credential doesn't want to be inherited by the 'root' process, but DOES want to be inherited by the second 'joe'. The idea of a credential being associated with a process rather than referenced by a process is quite broken. especially given the large mass of UNIX software that exists that doesn't do a "getsmbuid"/"setsmbuid" (said "smbuid" needing to be astructure to contain the authentication data -- namely the SMB password -- for reference instances). It gets worse, and the worse it gets, the more it looks like a rewrite of the credential mechanism in UNIX systems to deal with the issue in broad strokes. The fine details of "how do I create a non-UNIX credential associated with a UNIX credential when the only UNIX credential creation tool is setuid/setgid in login" is almost a secondary concern. I've thought a little bit about this problem before. 8-(. 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?199509131958.MAA08030>