Some linux-cifs-client ideas

[Simo Sorce]

I and Steve had a long discussion one evening at the CIFS conference.
We talked of some interesting possible developments, that are close to
what Stefan is asking here :-)

On Mon, 2004-08-23 at 17:49, David Collier-Brown wrote:
> > 1. What we want
> > 
> > - - Every unix user should be able to mount and umount cifs shares when 
> > he wants it,
> > ~  so not only at login time. (using it's own credentials: user/dom/pass 
> > or krb5...)
> 
> 	Yes, preferably using either the system default means ("user" or
> 	"users" on a mount line, or a mechanism other than the standard
> 	mount, as you describe below.

Well being able to mount a filesystem or not should still be in control
and permitted only by root, but we discussed about this bit.

1. We need a mechanism to ask userland about credentials so that when a
user cd into another user's directory the kernel is able to ask userland
about credentials.

For that we will probably need a facility in /proc or in a new virtual
filesystem (/cifs may be a good name).

The idea is to use kernel notifies so that each user can attach a
process on that virtual file and ask the kernel to notify any change (eg
/cifs/.usrnotify/).

This makes it possible for the cifsvfs module to signal the process it
needs credentials.
At this point, given a timeout, the cifsvfs will wait for the user to
give it the credentials needed (some way to pass data will have to be
provided, maybe an ioctl).

2. We need a mechanism to cache credentials in case we get disconnected
from the server or events like that, Steve told me that someone is
building a generalized kernel facility to store credentials, so I think
we can use that too and be consistent. (I can't remember the project
name, Steve can probably send in some pointer).

3. we need a way to tell the system to forget credentials.

> > 2. Aproach
> > 
> > - - having a virtuell cifs filesystem (like sysfs) mounted on /cifs
> > ~  every unix user should have its own view of this filesystem.
> > ~  (this file system will be mounted at boot time).
> 
> 	Yes, very much so!  I use smbfs, and find the virtual /smb
> 	directory very useful and, more importantly, easy to explain
> 	to others.

Yes, it is really a good thing(TM) for normal users.
Being able to just browse the network neighbourhood and open files over
the net without having to bother about mounting things is really really
important for any decent desktop things imho.
I think that having an cifs/network/workgroup/server/share/... model
would really be greatly beneficial for all desktop systems.
Beeing still able to mount a specific share in a specific point of the
filesystem too.

> > - - this filesystem has a /cifs/.ioctl file which is the io port for a 
> > tool 'cifsmount'
> > ~  this will ask the virtuell filesystem to mount or unmount cifs shares.

I don't think we should do this, just let the user navigate a virtual
directory tree that represents the network and let him do all the usual
file operations.

> > - - this shares will appear in /cifs/* ( or maybe /cifs/mnt/)
> 
> 	or perhaps /cifs/domain/server/share or /cifs/server/share?
> 
> > ~  (maybe also there will be a /cifs/network/ directory with
> > ~   subdirectories for each known domain and subdirs for servers ...
> > ~   just like the windows network neighborhood)
> 
> 	I'd try to make it as simple an elegant as possible,
> 	so that you can mount on read of a given share in
> 	a network neighborhood-like hierarchy.

yes this was proposed, plus the cifsvfs will be required to do a new
sessteup on each server a user goes into by cd-ing this virtual
filesystem using it's credentials (or asking for new ones if the given
ones does not work).

> > - - there will be a /etc/cifsmount.conf and a per user ~/.cifsmount/config
> > ~  for configuration stuff like auth protocol( e.g. disallow lanman...)
> > ~  and other stuff

I'm not sure this is a good idea, having a kernel module to read user
conf files is not really a good thing.

> > - - and for making it easier for the users there could be symlink ~/cifs 
> > to /cifs
> > ~  in the home directory

I don't think this is a good idea for a kernel module too messy.

> > 3. Problems
> > 
> > - - that would also solve the problem, of what default uid/gid the files 
> > should have,
> > ~  just use the ones from the user...
> 
> 	If I mount /cifs/homes/davecb, as either root or a user, it
> 	should be mounted with the owner being the unix (windows)
> 	owner of the remote filesystem, and the group the unix group
> 	of the remote filesystem. This allows the built-in access
> 	checks in Unix to work, and allow me to cd to, for example,
> 	/cifs/homes/joycecb and read files if an only if joyce made
> 	them readable to me.

The credentials used should be the one of the user accessing the
filesystem regardless of who mounted it. The cifsvfs just need to issue
anew sessetup if a different user walks the mount point.
Windows Credentials will be tied to a specific uid/gid(or gids).

> > - - as I'm not a kernel specialist, I'm not sure if there will be problems
> > ~  maybe with setuid() and friends.
> 
> 	I'd suggest mimicking the mount options of nfs: The important
> 	ones are nosuid, and for performance, noatime and noquota.
> 	Other interesting ones are ro, bg, intr, remount, rsize=n
> 	and wsize=n.

most of them are not suitable or does not make sense for cifs. Cifs must
have it's own set of options it is really a different filesystem with a
different approach, semantics and security model.

> 	Likely setuid won't be a problem, but it makes sense to have a
> 	way of setting the bit that makes mount ignore suid files
> 	is desirable.

No, with UNIX CIFS extensions it can be potentially a problem. And with
the next UNIX Extension in Samba we should have a complete Unix semantic
server so each bit need to be considered carefully.

Simo.

-- 
Simo Sorce    -  idra at samba.org
Samba Team    -  http://www.samba.org
Italian Site  -  http://samba.xsec.it