smbmount/mount interaction

[Urban Widmark]

Hello,

I'm looking for some (user & technical) feedback on a change I'm
considering on how mount and smbmount works together.

The current way mounts are done are:
    mount -t smbfs ... => smbmount ... => smbmnt
Possibly without the mount step. smbmount stays as a daemon and reconnects
when asked (unless it crashes).

Problems:
 - Some mount options should affect if the mount is allowed (eg user) or
   when it is done (eg auto). Some can just be ignored (auto) while others
   probably need handling (noexec, noatime).
 - Making smbmount parse /etc/fstab and/or duplicating what mount does for
   those options is bad.
 - smbfs doesn't work today from /etc/fstab as users expect.
 - Having one smbmount daemon per smbfs mount wastes memory.


Nothing prevents mount from mounting smbfs directly, without going through
smbmount. Removing one mount-time test from smbfs makes that work now,
although the mount can't actually be used for anything. What is needed
then is a way for smbfs to get a connection to the smb server.

Transforming smbmount into "smbconnect" would solve that. smbfs would
execute smbconnect whenever it needed a new connection (run it as the user
who made the mount and feed it all the options given at mount time),
similar to how the kernel runs modprobe.

This has the advantage of making smbfs look much more like a "regular"
filesystem.


Getting a password from the user would probably require a small change to
the mount utility (read prompt or USER/PASSWORD environment vars).

Browsing tools, like LinNeighbourhood, and others that currently rely on
the suid-smbmnt rules of "you can mount on anything you own" may want to
keep smbmnt in some form.


Comments?  This is a "not-until-kernel-2.5-or-something" change.

/Urban