Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When mounting a share as root with kerberos, cifs.upcall will always use
the ticket of root (/tmp/krb5cc_0) instead the one of the user specified
with 'uid=' or 'user=':
I do:
# mount.cifs -o user=walteste,uid=walteste,sec=krb5 '//nas-nethz-users.d.ethz.ch/share-w-$' /mnt
In the logs I see this:
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_0 is valid ccache
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_50515_glVIiD
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: /tmp/krb5cc_50515_glVIiD is owned by 50515, not 0
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_42474_6j8kJD
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: /tmp/krb5cc_42474_6j8kJD is owned by 42474, not 0
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_50515_aZvk46
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: /tmp/krb5cc_50515_aZvk46 is owned by 50515, not 0
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_50515_B96At9
Jan 5 14:26:57 osaka cifs.upcall: find_krb5_cc: /tmp/krb5cc_50515_B96At9 is owned by 50515, not 0
The '-l' option of cifs.upcall seems to be intended to address this but it
is not implemented:
# cifs.upcall -l
cifs.upcall: invalid option -- 'l'
Version-Release number of selected component (if applicable):
cifs-utils-4.4-5
Steps to Reproduce:
1. Log in as the user who owns the share and do a 'kinit' to get a ticket
2. As root get a ticket for some other user, e.g., via keytab
3. As root mount the share with sec=krb5 and user/uid options specified
Actual results:
Share is mounted but the user has no access.
Expected results:
Share is mounted and user can access files.
This is correct behavior. If you require the legacy behavior from cifs.upcall, then please specify the --legacy-uid flag in request-key.conf. See the cifs.upcall manpage for more info.
Ok, I've just sent a couple of patches to the list and to you that should fix this bug (and another, related bug that causes a segfault). Are you able to test these and let me know if they fix the problem?
I Installed cifs-utils-4.7-4.el6 on my test systems and that accepts the '-l'
option just fine and the mount works. Thanks a lot.
When will this patch make it to the regular RHEL6 updates? Will it help if
I also open a case at access.redhat.com?
Great, thanks for testing it. It should make 6.1. Opening a case at access.redhat.com would be ideal. When you do so, be sure to reference this BZ so that they know that it's a known bug with a pending fix.
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-2011-0569.html