[linux-cifs-client] [PATCH 3/5] [CIFS] change cifs_setup_session to take a unc string arg

[simo]

On Wed, 2007-10-31 at 17:37 +0300, Q (Igor Mammedov) wrote:
> Simo Sorce wrote:
> > On Tue, 2007-10-30 at 12:45 -0400, Jeff Layton wrote:
> >> On Tue, 30 Oct 2007 19:30:18 +0300
> >> "Q (Igor Mammedov)" <qwerty0987654321 at mail.ru> wrote:
> >>
> >>> Jeff Layton wrote:
> >>>> +
> >>>>  int cifs_setup_session(unsigned int xid, struct cifsSesInfo
> >>>> *pSesInfo,
> >>>> -					   struct nls_table
> >>>> *nls_info)
> >>>> +			struct nls_table *nls_info, const char
> >>>> *unc) {
> >>>>  	int rc = 0;
> >>>>  	char ntlm_session_key[CIFS_SESS_KEY_SIZE];
> >>>>  	int ntlmv2_flag = FALSE;
> >>>>  	int first_time = 0;
> >>>> +	char *hostname;
> >>>> +
> >>>> +	hostname = extract_hostname_from_unc(unc);
> >>> We already have server's IP and userspace helper could easily do
> >>> reverse lookup to find out server name.
> >>> Benefits:
> >>>     1. readability, simplicity: no need in adding additional argument 
> >>> and function (less changes)
> >>>     2. security: force administrators to do correct dns
> >>> configuration. ( 	FQDN -> IP -> FQDN )
> >>>
> >> That was my thought too, but Simo seems to believe that that won't be
> >> reliable enough and that admins may not have control of their
> >> in-addr.arpa domains.
> >>
> >> Simo, care to comment?
> > 
> > Yes, unfortunately in many cases, even in enterprise controlled
> > environments, DNSs are not necessarily well configured, and when AD is
> > involved even more so (I have no real numbers so take this with a grain
> > of salt). In these environments making changes to the DNS sometimes may
> > require a lot of time/effort.
> 
> Usually under "security" soup it is possible to enforce policy for 
> correct reverse zone configuration, almost anywhere. The reason for not 
> doing so lays in unwillingness to fix things if they somehow work 
> (admins usually say don't touch it if it works).

Well there are many cases where this stuff is not used in an official
way. Samba servers started like that in many companies, they were just
working (security = server) and later on became "official".
I would not like to exclude early adopters and testers because of
policies we would like to mandate.
I like the rule: be liberal in what you accept, be strict in what you
send out.

> > In these cases it would be nice to be able to still function as much as
> > we can.
> > Keep in mind that FQDN is indispensable to acquire the ticket, so
> > requiring IP->FQDN means some people would not be able to make Kerberos
> > authentication work except by using tricks like setting fixed entries
> > in /etc/hosts
> 
> If we look at NFS4+krb5 it also require reverse lookup and not only for 
> server but for clients too in some cases. In our case we could enforce 
> correct reverse lookup only for servers.
> I've looked through number of HOWTOs for kerberized servers/services and 
> saw that reverse lookup is usually MUST requirement for them. So it 
> could not be not issue in our case at all.
> We in no way affect TGT/TGS handling on a client side, it seems kerberos 
> has quite lax rules for reverse lookup here. (my client test pc doesn't 
> have any dns record about itself and TGT/TGS tickets handling works ).
> 
> More over if we don't force this now we could end up with errors in 
> kerberos code.

Uhmm I can't see any particular "error", what do you have in mind?
Maybe we can make it optional in the client to verify the address, like
it is for kerberos libs, and just support both scenarios.

> > In any case if we want to force this we need to document it prominently
> > IMO.
> 
> We could document it in mount.cifs.8 man page in the description of sec 
> option.

And also in the user space program man page.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>