Bug 517195

This is actually fairly tricky to get right, and fixing it isn't trivial. The problem is that cifs.upcall gets spawned by the kernel and doesn't have an easy way to know what the KRB5CCNAME env var is.

I pushed a kernel patch upstream a while back to add a pid= option to the upcall option string. I also did a patch that made cifs.upcall take that info and scrape the $KRB5CCNAME out of /proc/pid/environ. Unfortunately, that's not quite what's needed here and I need to rework that patchset.

The problem is that on a reconnect, there's no guarantee that process that kicks off the upcall has the right uid and KRB5CCNAME var. What we probably need to do is something like:

1) scan /tmp and look for files that seem like credcaches (have names that start with krb5_)

2) stat those files, if they aren't owned by the correct uid, then go to the next entry

3) if they are owned by the correct uid, open the credcache and see if it has a TGT for the correct realm.

...that may also mean that we need another kernel patch for the upcall to pass the domain= option to the upcall so that it knows what realm to work with.

All in all, there are a lot of little pieces that have to be fixed to get this right. I'll put this on 5.5 proposed for now, but it may not make it.

Patch sent to upstream mailing lists:

http://lists.samba.org/archive/linux-cifs-client/2009-August/005204.html

Patch committed to upstream samba master repo this morning. I'll see what can be done to backport the functionality for RHEL.

Created attachment 364516 [details]
patch -- update cifs.upcall to latest upstream version

After looking over the changes upstream, I came to the conclusion that it was easiest to just pull back the latest cifs.upcall.c and tweak it so that it'll build in 3.0.33. This patch represents that.

Hi there, this looks so promising.

I have just downloaded samba-3.0.33-3.15.el5_4.src.rpm and rebuilt the RPM's with your patch.

'cifs.upcall -v' now reports version 1.3 but I still get the 'Required key not available' error when trying to mount cifs shares as a user.

My users are all in AD (not local), a quick 'klist' does show a valid kerberos ticket.

Am I missing something obvious?

If at all interested there is a thread about my woes here:
http://www.linuxquestions.org/questions/linux-server-73/automounting-windows-share-using-users-kerberos-ticket-750347/#post3778264

I'm not sure. There are a lot of things that can go wrong in the krb5 mounting codepath. Make sure you have the keyutils package installed and that /etc/request-key.conf is set up properly. If that doesn't fix it then you'll probably want to open a support case and we can then work with you to troubleshoot it.

Should also mention for GD...

This patchset does not contain the patches you did upstream to make this build correctly against heimdal. I figured those didn't really matter for RHEL. If you think otherwise, I can respin the patch (or you can just add those on top).

(In reply to comment #13)
> Should also mention for GD...
> 
> This patchset does not contain the patches you did upstream to make this build
> correctly against heimdal. I figured those didn't really matter for RHEL. If
> you think otherwise, I can respin the patch (or you can just add those on top).

No, I think its fine to skip them here.

~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.

Event posted on 24-02-2010 09:53am GMT by mmyllyne

Hi,

unfortunately I'm still seeing this with 5.5 Beta. Everything works
perfectly when I have my Kerberos credentials in the default file
/tmp/krb5cc_$UID. When doing

export KRB5CCNAME=/tmp/foo
mv /tmp/krb5cc_$UID $KRB5CCNAME

I see klist still finding the credentials properly but mount.cifs start to
fail with error -126 (Required key not available). Doing

mv $KRB5CCNAME /tmp/krb5cc_$UID

will cause klist to fail as expected (since KRB5CCNAME is pointing to a
non-existing file now) but mount.cifs starts to work.

Thanks.

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by jhird 
 issue 360894

(In reply to comment #23)

> export KRB5CCNAME=/tmp/foo
> mv /tmp/krb5cc_$UID $KRB5CCNAME
> 

That won't work -- the cifs.upcall code only looks at filenames that it thinks might be candidates for a credential cache:

#define CIFS_DEFAULT_KRB5_DIR           "/tmp"
#define CIFS_DEFAULT_KRB5_PREFIX        "krb5cc_"

...this means that it only looks in "/tmp" and only at filenames that start with "krb5cc_".

Event posted on 24-02-2010 02:01pm GMT by mmyllyne

Hi,

I now retested using the expected path prefix for cache files (i.e., under
/tmp and filenames starting with "krb5cc_") and I'm happy to confirm
that all works now ok.

Thanks!

Internal Status set to 'Waiting on Support'

This event sent from IssueTracker by jhird 
 issue 360894

Hi, we have the same problem here. Upgraded to RHEL 5.5 beta, but problem persists. But we're using the samba-3.3.8 packages because we need kerberos signed packets (sec=krb5i). Is it possible that the cifs.upocall patch was added to the 3.0.33 packages but not 3.3.8? 

If this is the case, please give this info to the support folks. There is an open service request 1999610 for this issue (albeit we thought about a different cause). 

TIA!

The patches seem to have gone into this version:

* Tue Dec 22 2009 Guenther Deschner <gdeschner> - 3.3.8-0.48
- Update cifs.upcall to upstream version 
- resolves: #548129

...what samba3x package do you have installed?

Hi Guenther,

it's the samba3x-client-3.3.8-0.50.el5.i386.rpm package. Bug me if you need any more info. We have multiple AD domains. In one it works Just Fine [TM], in others it doesn't.

Harald, it sounds then like the problem you're having is unrelated to these patches. This patchset was intended to allow cifs.upcall to find credential caches with non-default filenames.

Jeff, you're probably right. I just can't figure out why

- Domain A behaves differently from other domains (ok we may need to take the ADs apart to see if there are any differences despite they were all auto-installed from the same configs and sources),
- why "mount.cifs -o uid=0,gid=0" would work in the problematic domains - timing problem with winbind (using idmap rid) - and omitting uid=,gid= or inserting the winbind provided uid/gid pair would not.

I should add that in the problematic domains, I don't even get a cifs/ service principal when attempting to mount, while in OK domains I do (I did a klist before / after). I will try to log cifs.upcall separately (as in #565446) and see if it's a cifs.upcall problem at all. 

Any AD expert to have an idea what might be configured differently?

It's getting weirder, folks. I changed from using pam_krb5 to pam_winbind as suggested by the RH support hotline (although I can't see what difference it should make when using "krb5_auth krb5_ccache_type=FILE" except that pam_winbind generates a krb5cc_$UID file and pam_krb5.so generates krb5cc_$UID_(random 6-char string) (is that a pam_krb5 feature or a bug? does cifs.upcall handle that correctly?). After that change, I can't mount my shares in the OK domain any more - "126 Required key not available". Let's see what happens. I set cifsFYI to 7 and syslog to log daemon.debug (i.e. cifs.upcall) separately. Realm names are masked for customer's privacy. 

The relevant portion of /etc/request-key.conf reads:

create       cifs.spnego    * * /usr/sbin/cifs.upcall %k
create       dns_resolver   * * /usr/sbin/cifs.upcall %k


First mount attempt with no uid= option: 

Mar 18 09:48:34 fwuserpc4 cifs.upcall: key description: cifs.spnego;0;10513;3f000000;ver=0x2;host=FS0Z0LLQ;ip4=10.63.84.228;sec=mskrb5;uid=0x3d13;user=user04
Mar 18 09:48:34 fwuserpc4 cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Mar 18 09:48:34 fwuserpc4 cifs.upcall: find_krb5_cc: /tmp/krb5cc_0 is owned by 0, not 15635
Mar 18 09:48:34 fwuserpc4 cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_15635
Mar 18 09:48:34 fwuserpc4 cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_15635 is valid ccache
Mar 18 09:48:34 fwuserpc4 cifs.upcall: handle_krb5_mech: getting service ticket for cifs/FS0Z0LLQ
Mar 18 09:48:34 fwuserpc4 cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328160)
Mar 18 09:48:34 fwuserpc4 cifs.upcall: handle_krb5_mech: getting service ticket for host/FS0Z0LLQ
Mar 18 09:48:34 fwuserpc4 cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328160)

Second mount attempt with uid=0:

Mar 18 09:49:09 fwuserpc4 cifs.upcall: key description: cifs.spnego;0;10513;3f000000;ver=0x2;host=FS0Z0LLQ;ip4=10.63.84.228;sec=mskrb5;uid=0x0;user=user04
Mar 18 09:49:09 fwuserpc4 cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Mar 18 09:49:09 fwuserpc4 cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_0 is valid ccache
Mar 18 09:49:09 fwuserpc4 cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_15635
Mar 18 09:49:09 fwuserpc4 cifs.upcall: find_krb5_cc: /tmp/krb5cc_15635 is owned by 15635, not 0
Mar 18 09:49:09 fwuserpc4 cifs.upcall: handle_krb5_mech: getting service ticket for cifs/FS0Z0LLQ
Mar 18 09:49:09 fwuserpc4 cifs.upcall: handle_krb5_mech: obtained service ticket

Mounting works, and the mount point and everything below belongs to root. After that, *root* has a cifs/ service principal, and USER has not: 

[root@fwuserpc4 cifs]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: superuser.CUSTOMER.DE

Valid starting     Expires            Service principal
03/18/10 09:35:28  03/18/10 21:35:34  krbtgt/R8611.ADS.CUSTOMER.DE.CUSTOMER.DE
        renew until 03/19/10 09:35:28
03/18/10 09:40:22  03/18/10 21:35:34  cifs/FS0Z0LLQ.CUSTOMER.DE
        renew until 03/19/10 09:35:28


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

[user04@fwuserpc4 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_15635
Default principal: user04.CUSTOMER.DE

Valid starting     Expires            Service principal
03/18/10 09:41:16  03/18/10 21:41:16  krbtgt/R8611.ADS.CUSTOMER.DE.CUSTOMER.DE
        renew until 03/25/10 09:36:38


Kerberos 4 ticket cache: /tmp/tkt15635
klist: You have no tickets cached



The relevant part of cifsFYI = 7:

First mount attempt w/o uid=

 fs/cifs/cifsfs.c: Devname: //FS0Z0LLQ/Users/user04 flags: 64 
 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 21 with uid: 0
 fs/cifs/connect.c: prefix path /user04
 fs/cifs/connect.c: Username: user04
 fs/cifs/connect.c: UNC: \\FS0Z0LLQ\Users ip: 10.63.84.228
 fs/cifs/connect.c: Socket created
 fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x1b58
 fs/cifs/connect.c: Existing smb sess not found
 fs/cifs/connect.c: Demultiplex PID: 4165
 fs/cifs/cifssmb.c: secFlags 0x1009
 fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
 fs/cifs/transport.c: For smb_command 114
 fs/cifs/transport.c: Sending smb:  total_len 82
 fs/cifs/connect.c: rfc1002 length 0xbf
 fs/cifs/cifssmb.c: Dialect: 2
 fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
 fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
 fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
 fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
 fs/cifs/asn1.c: Need to call asn1_octets_decode() function for fs0z0llq$@R8611.ADS.CUSTOMER.DE
 fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
 fs/cifs/cifssmb.c: negprot rc 0
 fs/cifs/connect.c: Security Mode: 0xf Capabilities: 0x8001f3fd TimeAdjust: -3600
 fs/cifs/sess.c: sess setup type 7
 fs/cifs/cifs_spnego.c: key description = ver=0x2;host=FS0Z0LLQ;ip4=10.63.84.228;sec=mskrb5;uid=0x3d13;user=user04
 fs/cifs/sess.c: ssetup freeing small buf f23ae200
 CIFS VFS: Send error in SessSetup = -126
 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 21) rc = -126
 CIFS VFS: cifs_mount failed w/return code = -126

Second mount attempt w/ uid=0:

 fs/cifs/cifsfs.c: Devname: //FS0Z0LLQ/Users/user04 flags: 64 
 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 22 with uid: 0
 fs/cifs/connect.c: prefix path /user04
 fs/cifs/connect.c: Username: user04
 fs/cifs/connect.c: UNC: \\FS0Z0LLQ\Users ip: 10.63.84.228
 fs/cifs/connect.c: Socket created
 fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x1b58
 fs/cifs/connect.c: Existing smb sess not found
 fs/cifs/connect.c: Demultiplex PID: 4170
 fs/cifs/cifssmb.c: secFlags 0x1009
 fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
 fs/cifs/transport.c: For smb_command 114
 fs/cifs/transport.c: Sending smb:  total_len 82
 fs/cifs/connect.c: rfc1002 length 0xbf
 fs/cifs/cifssmb.c: Dialect: 2
 fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
 fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
 fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
 fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
 fs/cifs/asn1.c: Need to call asn1_octets_decode() function for fs0z0llq$@R8611.ADS.CUSTOMER.DE
 fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
 fs/cifs/cifssmb.c: negprot rc 0
 fs/cifs/connect.c: Security Mode: 0xf Capabilities: 0x8001f3fd TimeAdjust: -3600
 fs/cifs/sess.c: sess setup type 7
 fs/cifs/cifs_spnego.c: key description = ver=0x2;host=FS0Z0LLQ;ip4=10.63.84.228;sec=mskrb5;uid=0x0;user=user04
 fs/cifs/transport.c: For smb_command 115
 fs/cifs/transport.c: Sending smb:  total_len 3630
 fs/cifs/connect.c: rfc1002 length 0xd5
 fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
 fs/cifs/sess.c: ssetup rc from sendrecv2 is 0
 fs/cifs/sess.c: UID = 53248 
 fs/cifs/sess.c: bleft 139
 fs/cifs/sess.c: serverOS=Windows Server 2003 R2 3790 Service Pack 2
 fs/cifs/sess.c: serverNOS=Windows Server 2003 R2 5.2
 fs/cifs/sess.c: ssetup freeing small buf f23ae740
 fs/cifs/connect.c: CIFS Session Established successfully
 fs/cifs/connect.c: file mode: 0x1b0  dir mode: 0x1f8
 fs/cifs/transport.c: For smb_command 117
 fs/cifs/transport.c: Sending smb:  total_len 88
 fs/cifs/connect.c: rfc1002 length 0x42
 fs/cifs/connect.c: disk share connection
 fs/cifs/connect.c: nativeFileSystem=NTFS
 fs/cifs/connect.c: Tcon flags: 0x1 
 fs/cifs/connect.c: CIFS Tcon rc = 0
 fs/cifs/cifssmb.c: In QFSDeviceInfo
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 72
 fs/cifs/connect.c: rfc1002 length 0x44
 fs/cifs/cifssmb.c: In QFSAttributeInfo
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 72
 fs/cifs/connect.c: rfc1002 length 0x50
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 90
 fs/cifs/connect.c: rfc1002 length 0xac
 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 22) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_iget as Xid: 23 with uid: 0
 fs/cifs/inode.c: Getting info on \user04
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 90
 fs/cifs/connect.c: rfc1002 length 0xac
 fs/cifs/inode.c: Old time 0
 fs/cifs/inode.c: New time 765739
SELinux: initialized (dev cifs, type cifs), uses genfs_contexts
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 24 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 766760
 fs/cifs/inode.c: Getting info on \user04
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 90
 fs/cifs/connect.c: rfc1002 length 0xac
 fs/cifs/inode.c: Old time 765739
 fs/cifs/inode.c: New time 766761
 fs/cifs/inode.c: cifs_revalidate - inode unchanged
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 24) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 25 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 766763
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 25) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 26 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 766763
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 26) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 27 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 822249
 fs/cifs/inode.c: Getting info on \user04
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 90
 fs/cifs/connect.c: rfc1002 length 0xac
 fs/cifs/inode.c: Old time 766761
 fs/cifs/inode.c: New time 822250
 fs/cifs/inode.c: cifs_revalidate - inode unchanged
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 27) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 28 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 822726
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 28) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 29 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 822864
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 29) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 30 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 822903
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 30) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 31 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 1092294
 fs/cifs/inode.c: Getting info on \user04
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 90
 fs/cifs/connect.c: rfc1002 length 0xac
 fs/cifs/inode.c: Old time 822250
 fs/cifs/inode.c: New time 1092295
 fs/cifs/inode.c: cifs_revalidate - inode unchanged
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 31) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 32 with uid: 15635
 fs/cifs/inode.c: Revalidate: \user04 inode 0xf1363e30 count 1 dentry: 0xf10ad4d0 d_time 0 jiffies 1092299
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 32) rc = 0



Apparently, cifs.upcall fails when getting a cifs/ service pricipal for users in the AD. BTW when I attempt a mount with another local uid != 0, cifs.upcall fails with:

Mar 18 10:04:55 fwuserpc4 cifs.upcall: key description: cifs.spnego;0;10513;3f000000;ver=0x2;host=FS0Z0LLQ;ip4=10.63.84.228;sec=mskrb5;uid=0x1f4;user=user04
Mar 18 10:04:55 fwuserpc4 cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Mar 18 10:04:55 fwuserpc4 cifs.upcall: find_krb5_cc: /tmp/krb5cc_0 is owned by 0, not 500
Mar 18 10:04:55 fwuserpc4 cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_15635
Mar 18 10:04:55 fwuserpc4 cifs.upcall: find_krb5_cc: /tmp/krb5cc_15635 is owned by 15635, not 500
Mar 18 10:04:55 fwuserpc4 cifs.upcall: handle_krb5_mech: getting service ticket for cifs/FS0Z0LLQ
Mar 18 10:04:55 fwuserpc4 cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328160)
Mar 18 10:04:55 fwuserpc4 cifs.upcall: handle_krb5_mech: getting service ticket for host/FS0Z0LLQ
Mar 18 10:04:55 fwuserpc4 cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328160)

Interestingly, in this case it tries to find a ticket cache for uid 500. Again, the mount command was invoked as user user04. Shouldn't cifs.upcall attempt to use the invoking user's ticket cache? 

I also think the mount.cifs (cifs.upcall?) behaviour re uid= is wrong. Methinks the option should only be used to explicitly set the ownership of the mounted share, and not interfere with getting a service ticket.

Hi, I rechecked what mount.cifs sends to the kernel - the uid= option is passed correctly (filled with the default uid=current_user if the user doesn't provide any). cifs.upcall apparently does the right thing, looking at its source code. It seems that keyctl_describe_alloc returns a key description with uid=0 (if set by the user), which makes cifs.upcall try to use krb5cc_0. 

As is happens, the root user has a domain admin TGT (just having joined the domain with it), and the $USER has a TGT with no special rights. Could that be the reason why the root's TGT does get a cifs/ service ticket and the $USER's does not? Is it that trivial? Needless to say, we checked that the very same user logged into a Vista box does get his shares, so we think it can't be the user's rights in AD.

I forgot to add that smbclient -k does it right. I can access the user's shares just fine - but then smbclient does not attempt to get a cifs/ service ticket. So it's not the user's right to access the share, but somehow he is not allowed to get a cifs/ service ticket. 

Strangely, in the "OK domain" mounting worked fine (also across file servers != DC) with pam_krb5.so enabled instead of pam_winbind. Difference: krb5cc file names.

The problem you're having sounds like something different than what this bug is about. I'm fairly certain that the cifs.upcall program in samba and samba3x do what they're intended to do, which is to find an alternate ccache instead of assuming that they should use the default name.

cifs.upcall and the kernel are definitely not set up to handle multiple krb5 realms, so that may be part of the issue here. I'll have to look over what you've posted so far to see if I can make sense of the problem. Either way, I think it would be a good idea to copy this discussion to a new bugzilla case and we can pursue it there.

Harald, can you open a new bug and copy the details to it? Even better would be to have support escalate this case to an RHBZ so they can also be involved. Once that's done, please cc be on the bug and I'll plan to pick it up.

Jeff, done. Please check #574750. support has been involved earlier, please check #1999610 (although the title is now obsolete).

Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
cifs.upcall performs certain CIFS-related tasks for the kernel in 
user space. The version of cifs.upcall included with previous versions 
of Samba could not provide the kernel with the credentials cache 
path stored in the KRB5CCNAME environment variable. Attempts to mount 
CIFS shares through fstab as a normal user would therefore fail. 
The version of cifs.upcall included with Red Hat Enterprise Linux 5.5 
can now provide the kernel with the credentials cache path, and 
CIFS shares can therefore be mounted for normal users.

Actually...that's not quite right.

The kernel doesn't pass on the KRB5CCNAME for several reasons. What the new code does is scan the directory where the krb5 credcaches are stored and then select the best candidate to use from from there. How about this instead?

------------[snip]-----------

cifs.upcall performs certain CIFS-related tasks for the kernel in user space. The version of cifs.upcall included with previous versions of Samba was not able to find and use Kerberos credential caches that used non-default filenames. The version of cifs.upcall included with Red Hat Enterprise Linux 5.5 will now search the credentials cache directory in order to find credentials caches with non-default filenames.

Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,8 +1 @@
-cifs.upcall performs certain CIFS-related tasks for the kernel in 
+cifs.upcall performs certain CIFS-related tasks for the kernel in user space. The version of cifs.upcall included with previous versions of Samba was not able to find and use Kerberos credential caches that used non-default filenames. The version of cifs.upcall included with Red Hat Enterprise Linux 5.5 will now search the credentials cache directory in order to find credentials caches with non-default filenames.-user space. The version of cifs.upcall included with previous versions 
-of Samba could not provide the kernel with the credentials cache 
-path stored in the KRB5CCNAME environment variable. Attempts to mount 
-CIFS shares through fstab as a normal user would therefore fail. 
-The version of cifs.upcall included with Red Hat Enterprise Linux 5.5 
-can now provide the kernel with the credentials cache path, and 
-CIFS shares can therefore be mounted for normal users.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0300.html

   	
Page Not Found (404)

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days