SMB filesystem
Quoted 16 lines · Jean-Eric Cuendet
[Currently], SMB access with Linux is done in the way:
- Mount a share
- Access it with rights defined at mount time.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.
Quoted 6 lines
What do you think of implementing it that way? Comments?
I'd like to implement it with libsmbclient.so, a samba provided lib that let you have access to workgroups/machines/shares in a MS network from Linux (or UNIX).
Then, it can't be kernel only. I need a userspace daemon
I've been hoping somebody would take this on.
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.
If you make the SMB token a property of the process, the 2nd program won't be able to access the files after the 1st program somehow triggers the user to log in.
Perhaps it should be kept in the kernel in the process group, so all processes in a process group can use the token?
- Dan
Quoted 2 lines · Dan Kegel
I've been hoping somebody would take this on.
Question: how will you carry the SMB token around?
How about using much the same approach that SSH uses - have a daemon that is launched from the user's .profile, that listens on an Unix domain socket created in the user's home directory and tracks the login tokens?
Additionally, that daemon could allow another user space program to listen to a socket, and be notified when a request for a non-existant token is made - this way when a user is running a GUI, the GUI could have a program that can pop up a prompt for the login, and then pass it on to the daemon, and then the daemon can inform the process that made the request to try again.
I do agree with some of the other posters, though - it seems to me the best approach would be a plug-in for autofs that used SMBFS.
Hi,
Thanks for your answer.
Why did you hope someone took this one? Do you think it's REALLY needed or is there non-solvable problems?
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.
For the token proprietary, it could be a file on the disk:/tmp/user.smb.token, like with kerberos
Or it could be a process attribute, like you suggest, but are all the processes of one user automatically in the same group? What about putting that in a ENV VAR?
Thanks for your help
-jec
I've been hoping somebody would take this on.
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.
If you make the SMB token a property of the process, the 2nd program won't be able to access the files after the 1st program somehow triggers the user to log in.
Perhaps it should be kept in the kernel in the process group, so all processes in a process group can use the token?
- Dan
Signature · 7 lines
Jean-Eric Cuendet Linkvest SA Av des Baumettes 19, 1020 Renens Switzerland Tel +41 21 632 9043 Fax +41 21 632 9090 E-mail: [email protected] http://www.linkvest.com --------------------------------------------------------
Quoted 12 lines · Jean-Eric Cuendet
Quoted 12 lines
Quoted 11 lines
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.
Quoted 5 lines
Quoted 2 lines
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.)
Quoted 16 lines
Quoted 6 lines
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.
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 1 line
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