This sounds very similar to what I proposed for the smbfs. You might consider
abstracting the ideas so the code can be reused for that filesystem too. And I
suspect some of it might be useful for kerberized nfs, or coda/afs as well.
> The down side of this, and the reason I'm asking for approval, is that the
> table of Netware IPX connections for each user would then have to be kept by
> the kernel. I don't like the idea of doing that, the only alternative I can see
> is to have the whole thing done in userspace as a local NFS mount, which is
> likely to be horribly slow.
Hm, maybe you don't need a single table anywhere. You could put a reference in
the process structure for the active set of filesystem credentials. This would
mean they would be inherited by setuid processes and generally behave like AFS
process authentication groups -- and have the same disadvantages.
Here's my old proposal for smbfs:
------- Start of forwarded message -------
Subject: How to cleanly integrate the smb security model in smbfs
From: Greg Stark <gsstark@mit.edu>
To: linux-kernel@vger.rutgers.edu
Cc: Bill Hawes <whawes@star.net>
Date: 23 Nov 1997 01:31:46 -0500
In the smbmount man page the following paragraph appears:
> If neither -n nor -P are given, smbmount prompts for a
> password. This makes it difficult to use in scripts
> such as /etc/rc. But that's not smbmount's fault, but a
> general problem with the Lan Manager security model. If
> anybody has a satisfying solution to this problem,
> please tell me.
Well, i have an idea that i think is very satisfying, but
it may be considered "too complex" or "too hard".
My idea is basically to multiplex the mount point amongst
all the users who need it. When a mount point is created
an smb session is (optionally) started as guest. Then the
user runs a client, say "smbauth", to authenticate and to
initiate smb sessions with their privileges. Each user is
given a mapping of mount points to smb sessions to use.
Then simply creating a mount would never need a password,
and multiple users could use the same mount with only the
privileges their own. As a result the mounts could be in
/etc/fstab just like any other filesystem.
This setup may seem strange but other filesystems already
do similar things. AFS has klog/aklog which users run to
push their credentials into the kernel which keeps track
of a uid->credentials mapping or stores the credential in
the process group list. Similarly in kerberized NFS users
run a program called nfsid to authenticate a principal to
uid mapping with the server.
In both cases a mount can be made without authenticating,
the client kernel keeps track of of credentials, usually
per-process and multi-plexes the connection to the server
amongst them. In the case of smb the credential is simply
the tcp connection. Each authenticated user needs a fresh
tcp connection and smbfs just assumes tcp connections are
safe to trust once made (though they aren't).
A typical usage in this setup might look like:
/etc/fstab:
/dev/hda1 /dos vfat noauto,user
//wfw/c /mnt/wfw-c smb defaults
//wfw/d /mnt/wfw-d smb noguest
//w95/c /mnt/w95-c smb noguest
Then when i log in:
$ ls /mnt/w95-c
ls: /mnt/w95-c: Permission denied
$ smbauth /mnt/w95-c
Password:
$ ls /mnt/w95-c
...
$ ls /mnt/wfw-c
... [with guest privileges]
$ smbauth --server wfw
Password:
$ ls /mnt/wfw-c
... [with my privileges]
or possibly:
$ smbauth --all
Password for wfw:
Password for w95:
------- End of forwarded message -------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu