<snip>
> ... It would be nice
> to have the equivalent functionality in Unix, hopefully in an user
> friendly fashion.
> ... the directory tree would look like:
> /net/
> smb/
> server1/
> fileservice
> printservice
> server2/
> C
> D
> nfs/
> server/
> vol1
> vol2
> I think this is a very neat idea (it's not mine). What do you think?
A fine plan, and one which I was considering looking into myself.
This would probably be best implemented using a version of autofs. Using a
different mount point (and daemon) for each type of filesystem is easier.
The top level of the filesystem, containing the names of the available servers,
could be generated by the daemon when the user calls readdir() in the root of
the filesystem. (This is different to the normal autofs behaviour of creating
subdirectories only when they're actually used)
Taking Netware as an example, when you change into (or readdir() ) the /Netware
directory the daemon could list the available servers and create the necessary
'directories'.
Then when you change into one of those 'directories' (/Netware/NCPSERVER/), it
will look up the available shares on that server and create directories for
each of them. Finally, when you enter a subdirectory of that
(/Netware/NCPSERVER/SYS), it will attempt to mount the volume.
This lot shouldn't be too hard to do, assuming autofs can be persuaded to
behave in the way we desire.
However, that's the easy bit - how would we handle authentication? It's not
possible to just bring up a login window when the user tries to change into a
remote directory. Furthermore, once we have managed to obtain a username an
password for the remote system, what permissions do we give to other users than
the one who logged in?
This is a problem even without automounting - when sharing a HOME volume from a
netware server in the past, I've always had to mount it in a different place
for each user, rather than having a single mount point, on which each user
employs their own authentication.
One possible solution that I've considered before is this:
1. The system administrator can set default username/password pairs for
logging in to certain machines, so any local user can use the volumes.
(In fact, the sysadm would probably also supply a set of permissions)
2. Individual users can register their own username/password/perms tuple, so
that they can access other servers, or access the default server with
their own credentials.
When the kernel tries to log in to a remote machine, it will use
authentication tuples in the following order of preference:
1. Authentication tuple registered by current->uid
2. System-wide authentication tuple registered by root
3. {"anonymous",""} and other such possibilities.
Unfortunately, this would wreak havoc on the local caching of remote
filesystems, which could then be entirely different depending on which user is
accessing the filesystem. But as we can't really cache very much anyway (from
my experience with NCPFS) that's hardly going to kill us - we just add a 'uid'
field to the cache entry, and a flag which says that the uid must be matched in
addition to the pathname.
Hmmm. I should be working....
Comments?
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 812896
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html