Mounting a workgroup or machine

[Peter Samuelson]

  [me]
> > The Network Neighborhood is a very un-Unixy entity, though.  It
> > works on Windows boxes because Microsoft is able to make some
> > simplifying assumptions that aren't too appropriate on Unix.  Two
> > that I can think of: (a) There is only one possible shell,
> > EXPLORER.EXE, and incest with kernel filesystem internals is not
> > considerd a problem; (b) There is only one user logged on, so
> > there's never any difficulty determining which set of credentials
> > to use.

[Peter J. Holzer]
> Both doesn't seem too much of a problem to me.
> 
> The shell (or other program) is irrelevant if there is a
> "workgroup-filesystem", which can be mounted. Each Host and Share should
> look just like a directory.

But the NN is by necessity a connect-on-demand architecture, sort of
like autofs.  If you can guarantee that only one application will need
to do NN enumeration, you can code up a proprietary extension to get
the details right.  Un-unixy.

> The second is a bit more complicated, and not really well implemented
> in smbfs.  However, I think this could be done better:

In Windows, the Explorer keeps a cache of your credentials for each
server, starting from the password you used to log on to the local
system.  This is doable in Unix userspace, but there are major security
implications of caching passwords, especially your primary logon
password.

I think what you would have to do is have a `userpasswdd' that starts
up from xdm or whatever and opens some sort of device in /dev.  Then it
polls this device waiting for the kernel to need a set of credentials,
upon which it supplies the appropriate ones, from its cache or by
popping up a dialog or whatever.  Then the kernel-side "autosmbfs" just 
has to check, every time it wants to connect to a share, to see if the
user in question has /dev/smbcreds open, and if so, queries the process 
in question.

Another major issue that Windows doesn't really have to deal with is
that Unix doesn't have private namespaces.  (Well, neither does
Windows, but since most Windows machines only have one user logged in
at once, it's not a problem.  I don't know how TSE deals with this.)
So if user A automounts /mnt/smb/server1/share1 and user B tries to
access this, should the kernel just let user B use those files with
user A's credentials, or should it reread the same information under
user B's creds?  If the namespaces aren't private, it is hard to detect
that /mnt/smb/server1/share1 needs to be automounted for user B even
though it already exists in the namespace.

NFS doesn't have this problem, because each NFS request is independent,
carrying its own set of credentials.  There is no actual
connect/disconnect action where a set of user credentials is supplied.

Kerberos doesn't have this problem, because it is implemented entirely
in user space and doesn't involve the filesystem namespace.

AFS -- well, I'm not sure about AFS, it's been a very long time since I
used it.

Peter