On Tue, 30 Jul 2013 13:35:47 +0200
Marcus Moeller <marcus.moeller@xxxxxx> wrote:
> Hi again,
>
> >>>>> On Mon, 29 Jul 2013 14:50:03 +0200
> >>>>> Marcus Moeller <marcus.moeller@xxxxxx> wrote:
> >>>>>
> >>>>>> [ 124.607810] fs/cifs/cifssmb.c: negprot rc 0
> >>>>>> [ 124.607814] fs/cifs/connect.c: Security Mode: 0xf Capabilities:
> >>>>>> 0x8001f3fc TimeAdjust: -7200
> >>>>>> [ 124.607817] fs/cifs/sess.c: sess setup type 4
> >>>>>> [ 124.607826] fs/cifs/cifs_spnego.c: key description =
> >>>>>> ver=0x2;host=d.ethz.ch;ip4=82.130.70.6;sec=krb5;uid=0xaf05;creduid=0xaf05;user=mam4tst;pid=0x61a
> >>>>>>
> >>>>>>
> >>>>>> [ 124.803185] fs/cifs/sess.c: ssetup freeing small buf
> >>>>>> ffff88022c31a000
> >>>>>> [ 124.803195] CIFS VFS: Send error in SessSetup = -126
> >>>>>> [ 124.803203] fs/cifs/connect.c: CIFS VFS: leaving
> >>>>>> cifs_get_smb_ses (xid = 5) rc = -126
> >>>>>> [ 124.803212] fs/cifs/fscache.c:
> >>>>>> cifs_fscache_release_client_cookie:
> >>>>>> (0xffff88022a1b6000/0xffff88022a6430f0)
> >>>>>> [ 124.803368] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
> >>>>>> = 4) rc = -126
> >>>>>> [ 124.803374] CIFS VFS: cifs_mount failed w/return code = -126
> >>>>>
> >>>>> The only failure I see is the one above, and that's because it failed
> >>>>> to upcall for the correct key. Are you sure you have krb5 creds as
> >>>>> that
> >>>>> user?
> >>>>
> >>>> Yes, creds are there and it also works when mounting from one of the
> >>>> servers directly.
> >>>>
> >>>> Only mounting using the domainname does not work.
> >>>>
> >>>>
> >>>>>> [ 131.324798] fs/cifs/cifssmb.c: negprot rc 0
> >>>>>> [ 131.324804] fs/cifs/connect.c: Security Mode: 0xf Capabilities:
> >>>>>> 0x8001f3fc TimeAdjust: -7200
> >>>>>> [ 131.324808] fs/cifs/sess.c: sess setup type 4
> >>>>>> [ 131.324821] fs/cifs/cifs_spnego.c: key description =
> >>>>>> ver=0x2;host=d.ethz.ch;ip4=172.31.65.62;sec=krb5;uid=0xaf05;creduid=0xaf05;user=mam4tst;pid=0x62c
>
> >>>>>> [ 131.384335] fs/cifs/transport.c: For smb_command 115
> >>>>>> [ 131.384344] fs/cifs/transport.c: Sending smb: smb_len=1666
> >>>>>> [ 131.387043] fs/cifs/connect.c: RFC1002 header 0xf9
> >>>>>> [ 131.387055] fs/cifs/misc.c: checkSMB Length: 0xfd,
> >>>>>> smb_buf_length: 0xf9
> >>>>>> [ 131.387095] fs/cifs/transport.c: cifs_sync_mid_result: cmd=115
> >>>>>> mid=2 state=4
> >>>>>> [ 131.387100] fs/cifs/misc.c: Null buffer passed to
> >>>>>> cifs_small_buf_release
> >>>>>
> >>>>> Here' the upcall for a similar set of creds worked fine. The only
> >>>>> thing
> >>>>> that seems to have changed in the key description is the IP address.
> >>>>>
> >>>>> Do you have cifs.upcall set up to use the --trust-dns flag? If so,
> >>>>> why?
> >>>>
> >>>> A relict from the past. I have removed it from the config. Thanks for
> >>>> pointing out.
>
> Sorry, I was wrong. Without the -t option I am not even able to mount it
> at all. The man page states a few words on that parameter, but I am
> still not sure how it works when -t is not set.
>
> With -t set, the initial problem with the domain lookup works, when
> reverse DNS is configured propably.
>
Ok, that makes sense then. The problem here is that the kernel needs to
know what service principal name to use when contacting the server, and
I suspect your krb5 configuration is not quite right.
It looks like you're doing something like:
mount //d.ethz.ch/dfs /mnt/dfs -o sec=krb5...
...at this point, what happens is that the kernel needs to get a krb5
service ticket to talk to the CIFS service on the host.
What it typically does is take the hostname in the UNC that you're
trying to mount, prepend it with "cifs/" and then try to get a service
ticket for that. In your case, it'll look something like this:
cifs/d.ethz.ch@xxxxxxxxxxxxxxxxxxxxxx
...now, typically if that fails, we'll give up. Trying to do anything
else is not considered safe since it's vulernable to DNS spoofing.
If however, you add the '-t' flag to cifs.upcall, that tells it to try
and guess the hostname part of that principal by reverse resolving it in
DNS. It takes the IP address to which you are connecting, does a
reverse DNS lookup and then uses that in the SPN.
This is less safe, since if your DNS server is compromised someone
could redirect you to a malicious server, and your client wouldn't be
able to trivially detect that. So it in effect waters down krb5
security.
The correct fix is to ensure that the server(s) to which you are
connecting have the ability to accept SPNs for the "hostnames" to which
you want to connect. That means that you need to add SPNs for
cifs/d.ethz.ch and ensure that the server will accept them to talk to
its cifs service.
Alternately, you can continue to use the '-t' flag and ensure that each
possible server accepts principals for the hostnames to which their IP
addresses reverse-resolve, with the caveat that its less safe than
doing that the "right way".
As to how to add these principals and make the server accept them...it
depends on the server.
Clear as mud?
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
