[linux-cifs-client] Re: Some linux-cifs-client ideas

[Steven French]

> I someone told me that you want to support that each user can use it's 
> own credentials when mounting
> a share on a cifs server...is that correct?
> 

/proc/fs/cifs/MultiUserMount is off by default (set to 0) but can be 
enabled.  It has not been tested recently since, after discussions with 
Simo et al, I would like to enhance some of the related code.  When it is 
enabled, it is supposed to use the smb_uid that corresponds to the Linux 
UID for that pid (if there is one - if not it uses the default - the 
smb_uid of the original mount) - but of course the problem is that this 
requires explicitly mounting more than once, once as each Linux UID while 
specifying the corresponding SMB username - so the client can get an 
smb_uid for each local uid that would access this mount.   It needs to 
allow an automated way of the kernel querying a pam helper (such as 
pam_mount perhaps - which claims to have cifs vfs support interestingly) 
or of optionally popping up a dialog and asking the user to input the 
desired username/password for the new UID accessing the mount.   There are 
lots of choices which can be experimented with and made configurable - but 
all require an upcall mechanism - which is being prototyped (there are 
various mediocre ways to do upcalls to userspace in Linux - but no clearly 
best way).  Suggestions on an really simple Linux upcall mechanism that 
could be reused trivially would be helpful (there are various issues with 
pointer conversions or deadlock that have scared me off the ones I have 
looked at so far).

> - - having a virtuell cifs filesystem (like sysfs) mounted on /cifs
> ~  every unix user should have its own view of this filesystem.

Simo talked about this idea too, and I like it, although I am not sure 
that I want to go as far as NFS has (its new fake filesystem - stores some 
information that should be accessible in other more structured ways).

> I use smbfs, and find the virtual /smb
> directory very useful and, more importantly, 
> easy to explain to others.

What virtual /smb directory is that? I have not seen this in the smbfs 
source code?  Is it another Linux dummy filesystem shipped by some 
distros?

> This allows the built-in access checks in Unix to work,

It is configurable on the cifs client (via a mount option) whether the 
local vfs_permission check is invoked.  I am not certain what should be 
the default.  My intuition is that if /proc/fs/cifs/MultiUserMount is 
enabled it is redundant, and somewhat misleading and error prone, to also 
do a local security check against a (potentially stale) set of mode bits 
in the client's copy of the inode.

>        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.

cifs already has nosuid & noexec (which are optional when root mounts, but 
always set by the cifs mount helper  when mount.cifs is run by a non-root 
user).  Noatime is an interesting idea - I will have to trace it and see 
if it has much of an effect in my case.   Noquota does not make sense (I 
don't think) - but I am not certain what it is supposed to control. Quotas 
do not pass into the Linux VFS unless you are a local filesystem - since 
the POSIX quota API is worthless unless you have a real device name (!) so 
I doubt that quotas could matter for a network client (unless you write 
your own pure userspace tools as NFS did) and of course a client is not 
allowed to turn off quotas on the server anyway.      ro, intr, rsize and 
wsize are implemented already in cifs. 

Need help understanding what bg does.   Also on remount - what I am I not 
doing that I should be doing - remount works I think - but I am not 
certain - the way this option works changed in the 2.6 vfs

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com