Mounting a workgroup or machine

[Peter J. Holzer]

On 2000-04-21 02:12:46 +1000, Peter Samuelson wrote:
> 
>   [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.

This shouldn't be application dependent. A filesystem can be used by all
applications. No userspace code involved, except some program to supply
credentials. 

> > 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.

Kerberos gets around this by using the login password only for the first
sign-on. Then a session key (ticket) is created which is used to
authenticate all further connections. (IIRC - it has been quite a few
years since I looked at Kerberos)

It may be possible to get something like this to work with current NT
and Samba servers, but I wouldn't count on it. Otherwise caching
passwords is the only way - an SMB server can disconnect at about any
time, and the client is supposed to reconnect. Also, the user may not be
around to type the password (think about cron jobs). 

> 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.

Yup, I was thinking about something like this.

> Another major issue that Windows doesn't really have to deal with is
> that Unix doesn't have private namespaces. 

Actually, it has, but they are limited to very small areas: /dev/tty for
example is a different device for each process group, although all
access it under the same name (and even see the same major and minor
number, timestamps, etc). Some Unixes have a /dev/fd/* hierarchy, or
portions of /proc which are different for every process. 

A network filesystem which looks different to different people would be
a straightforward extension.

> 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?

The latter, of course. You can't give one user permissions just because
some other user happened to access the same files before.


> 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.

I don't think so. You just have to keep the uid with every mounted
file system. You could even make it explicit in the file system
structure:

/<mountpoint>/<username>/<workgroup>/<server>/<share>

If a user does an ls on /<mountpoint>/, he will see a single directory
with his own username. The rest of the hierarchy will be accessed with
that username. If he has already entered credentials for other
usernames, he will see these directories, too. Or, if he tries to access
an "invisible" directory, the kernel will call back to the userpasswdd
to request the credentials.

Anybody who would like to implement this? I might write a more detailed
description, but I won't have time to code and debug it.

> NFS doesn't have this problem, because each NFS request is independent,
> carrying its own set of credentials. 

Actually, in NFS the user is never authenticated by the server. The
client machine just sends "this is a request for uid 4711", and the
server believes it.  

	hp

-- 
   _  | Peter J. Holzer      | E = mc²     -- Albert Einstein
|_|_) | Sysadmin WSR / LUGA  | E(M) = C    -- Bruce Schneier
| |   | hjp at wsr.ac.at        |   -- noticed by rain forest puppy
__/   | http://www.hjp.at/   |	    on bugtraq 2000-04-20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 371 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20000425/ba3bf0b6/attachment.bin