Re: cifs honor client <option> parameter in smb.conf

On Thu, 09 Apr 2009 17:25:28 +0530
Suresh Jayaraman <[email protected]> wrote:

> Jeff Layton wrote:
> > On Thu, 09 Apr 2009 16:58:00 +0530
> > Suresh Jayaraman <[email protected]> wrote:
> 
> >> Wondering whether cifs vfs client is supposed to honor or attempt to
> >> honor the client specific parameters in smb.conf. For e.g. an config
> >> entry such as:
> >>
> >>    client plaintext auth
> >>
> >> Currently, it seems with the above parameter in smb.conf, a cifs client
> >> won't be able to mount successfully with plaintext auth and will result
> >> in -EPERM error. Adjusting the SecurityFlags will allow the user to
> >> mount, though, but in that case the smb.conf entry is being ignored?
> >>
> > 
> > smb.conf is completely ignored by mount.cifs
> > 
> 
> Yes, I understand this. I was thinking whether any negotiation if
> possible with the server should happen and based on this cifs client
> should make decision/set SecurityFlags for that session.. as smb.conf
> documentation talks in general about  "all samba client tools"
> For e.g. this man page of smb.conf might be misleading thought:
> <snip>
>        client lanman auth (G)
> 
>            This parameter determines whether or not smbclient(8) and
> other samba client tools will attempt to authenticate itself to servers
> using the weaker LANMAN password hash.
> </snip>
> 
> Users that are used to smbclient would be expecting the similar
> behaviour from cifs. I think such options should clearly documented in
> smb.conf man page so that the fact that mount.cifs would be ignoring
> smb.conf client specific settings is visible to users.
> 

Agreed. That should be clarified in the mount.cifs manpage. Care to
post a patch?

I'm not sure it's a good idea to make mount.cifs respect smb.conf. I'm
already not thrilled with the way that smb.conf is used for both server
and client-side behavior. My preference would be to keep CIFS away from
it.

-- 
Jeff Layton <[email protected]>