Hi,
Actually, 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.
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 with which the
kernel will communicate, since the shared lib can't be added to the kernel.
How do you think is the best way of doing things?
Making a minimal FS kernel driver that communicate with a complex
userspace daemon?
Is it possible to implement a userspace filesystem? In which way?
Is there a generic interface in the kernel for userspace implemented
filesystems?
Where is the doc on that?
Thanks for comments/ideas.
-jec
Hi,
On Sun, 2 Jun 2002, Jean-Eric Cuendet wrote:
> [blah]
> How do you think is the best way of doing things?
> Making a minimal FS kernel driver that communicate with a complex
> userspace daemon?
Virtual loop device? Have an userspace daemon feed it into a loop device,
and make the kernel mount that. Just suggesting...
Regards,
Thunder
--
ship is leaving right on time | Thunder from the hill at ngforever
empty harbour, wave goodbye |
evacuation of the isle | free inhabitant not directly
caveman's paintings drowning | belonging anywhere
On Sun, Jun 02, 2002 at 11:00:13PM +0200, Jean-Eric Cuendet wrote:
...
> Then, it can't be kernel only. I need a userspace daemon with which the
> kernel will communicate, since the shared lib can't be added to the kernel.
> How do you think is the best way of doing things?
> Making a minimal FS kernel driver that communicate with a complex
> userspace daemon?
Look at how CODA, and especially Intermezzo do it.
> Thanks for comments/ideas.
> -jec
/Matti Aarnio
On Sun, Jun 02, 2002 at 11:00:13PM +0200, 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
[...]
> Thanks for comments/ideas.
Can this be done with autofs in userspace? It works for NFS, just cd to
/autofs-mountpoint/hostname.
Marius Gedminas
--
Any sufficiently advanced Operating System is indistinguishable from Linux.
-- Jim Dennis
On Sun, 2 Jun 2002, Jean-Eric Cuendet wrote:
> What do you think of implementing it that way? Comments?
I would do the browsing as one part and the smb file access as another.
That could allow a user to choose browsing implementation and file access
implementation independently. On the network level they have "nothing" in
common.
For info on user-space filesystems you should spend some more time with
google. There are people out there that have done that.
The browsing can be done as an add-on to autofs (in some form) or as a
userspace filesystem of its own.
Currently autofs has a problem where it won't show the mountpoints of
non-mounted directories, but I think you would run into that problem too.
(short version of the problem: how do you prevent 'ls -l' from mounting
all filesystems in a directory?)
/Urban
On Sun, Jun 02, 2002 at 11:34:59PM +0200, Urban Widmark wrote:
> Currently autofs has a problem where it won't show the mountpoints of
> non-mounted directories, but I think you would run into that problem too.
> (short version of the problem: how do you prevent 'ls -l' from mounting
> all filesystems in a directory?)
It would be nice to have this fixed, that is, to allow listing of
potential mountpoints, and ignore stat() on them instead of trying to
mount immediately.
BTW that's the only remaining feature that makes supermount more
"user-friendly" than autofs for floppies/CD-ROMs.
Marius Gedminas
--
... there is always a well-known solution to every human problem -- neat,
plausible, and wrong.
-- H. L. Mencken (1880-1956), "Prejudices"
Jean-Eric Cuendet wrote:
> [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.
>
> 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
Dan Kegel wrote:
> 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
--
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
--------------------------------------------------------
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
On Sun, 2 Jun 2002 23:34:59 +0200 (CEST), Urban Widmark <[email protected]> wrote:
> Currently autofs has a problem where it won't show the mountpoints of
> non-mounted directories, but I think you would run into that problem too.
> (short version of the problem: how do you prevent 'ls -l' from mounting
> all filesystems in a directory?)
You add the concept of a "light" lookup, and you make path_walk() call this
"light" lookup (be that a separate fs method, or a flag passed down to real
lookup()) iff the path component being looked up is the last component in
the path. A "light" lookup sets a flag in the inode signalling that the inode
is incomplete, so cached_lookup() can check this flag and call a "full"
lookup() (or perhaps a "full" revalidate()) if necessary.
The actual details need to be thought out a bit more, this is only a general
outline. In particular, we need a bullet-proof way to determine when to
"upgrade" the inode from "light" to "full".
You then also need to add a "getdents" kind of message to the autofs
protocol, and a "light lookup" message (which confirms the existence of the
entry, and maybe returns the type of the entry: symlink or directory).
Once all this is done, I'll add support for it in am-utils in a jiffy...
Ion (am-utils co-maintainer)
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Jun 03, 2002 18:45 -0400, Ion Badulescu wrote:
> On Sun, 2 Jun 2002 23:34:59 +0200 (CEST), Urban Widmark <[email protected]> wrote:
>
> > Currently autofs has a problem where it won't show the mountpoints of
> > non-mounted directories, but I think you would run into that problem too.
> > (short version of the problem: how do you prevent 'ls -l' from mounting
> > all filesystems in a directory?)
>
> You add the concept of a "light" lookup, and you make path_walk() call this
> "light" lookup (be that a separate fs method, or a flag passed down to real
> lookup()) iff the path component being looked up is the last component in
> the path. A "light" lookup sets a flag in the inode signalling that the inode
> is incomplete, so cached_lookup() can check this flag and call a "full"
> lookup() (or perhaps a "full" revalidate()) if necessary.
>
> The actual details need to be thought out a bit more, this is only a general
> outline. In particular, we need a bullet-proof way to determine when to
> "upgrade" the inode from "light" to "full".
This may fit nicely with some work we are doing for Lustre (a scalable
distributed filesystem for Linux) which needs to do "intent-based
lookups". It has a similar desire to separate the lookups of the start
of the path from the lookup of the last component of the path. Peter
Braam (CC'd) has a patch for 2.4.18 which implements this. I pass the
discussion over to him...
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/