[linux-cifs-client] Re: Some linux-cifs-client ideas
sfrench at us.ibm.com
Mon Aug 23 16:59:41 GMT 2004
> 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
> 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
Senior Software Engineer
Linux Technology Center - IBM Austin
email: sfrench at-sign us dot ibm dot com
More information about the samba-technical