Jean-Eric Cuendet wrote:
I'm thinking of implementing an smb filesystem, the way AFS implement the AFS client fs kernel driver.
- Mount the smb filesystem on /smb (done at boot time)
- Every user has list dir access on /smb
- There, you see each workgroup/domain available on the network
- Then in each domain, a list of machines
- Then in each machine, a list of shares
- Then a list of files/dirs
Access will be granted using the SMB token (like a kerberos ticket) issued by the primary domain controller. It's the way the windows explorer works. It's cool and useful.
Dan Kegel wrote: I've been hoping somebody would take this on.
Why did you hope someone took this one? Do you think it's REALLY needed or is there non-solvable problems?
I'm interested in the Wine project, in particular, the kernel module being developed to speed up execution of win32 programs. It would really benefit from what you're proposing. (Wine is currently starting to do its own SMB client stuff, probably using the same shared library you're proposing to use, but not in a way that would be usable by the wine kernel module, I think. Wine could use your enhanced smbfs, if present, to allow all file operations to be handled by the wine kernel module.)
Question: how will you carry the SMB token around? Let's imagine somebody starts a script that runs two programs that access SMB shares, and that they're initially not logged in at all. If this were Windows, it would prompt them once for their username and password, and then allow access from then on. ...
For The user/pwd problem, you are right, user should be prompted for a password. This could be achieve in the following way:
- If no token available: logged in anonymous or Guest
- The application could ask the daemon if a token is available, then
prompt the user for it before accessing the files.
- Make a generic callback way to call an arbitrary process
- When no token available, return a "NO LOGIN" message, so the
application should ask the user/password, create the token, or failed.
I think that 1 or 4 is the best way to do it.
I favor #4, it's the simplest. When the time comes that somebody wants closer emulation of windows behavior, something fancier could be done.
For the token [itself], it could be a file on the disk: /tmp/user.smb.token, like with kerberos
If that's how kerberos does it, that's probably fine. (In fact, in the future, won't you just use kerberos for a lot of windows networks?) But it might be awkward to access from inside the kernel, so I can imagine you might want to store it inside your smbfs kernel module instead.
What about putting that in a ENV VAR?
Nope, environment variables are not global enough.
Some posters have proposed using autofs to do the mounting. That's a good idea if it saves work and lets you have the per-user semantics you want. So all you need to do is implement an smbfs that uses the user's token to validate each open/rm/mv, and you're done. (Modulo somebody hooking an smb browser into an ldap server, but that may already have been done.) - Dan