mount.cifs cannot mount with kerberos

[ChrisCauser]

Binary package hint: cifs-utils

Please tell me if this is the wrong channel. I have put this in the ubuntu forum with no reply here:

http://ubuntuforums.org/showthread.php?t=1623107

From the thread:

mount.cifs used to be able to work with kerberos tickets so long as I changed the binary to suid root. I understand why this may have fallen out of favour but since Meerkat, I am unable to get mount.cifs to mount using kerberos and sudo.

# Non sudo mount.cifs with/without suid root
$ mount.cifs //server/share/directory ~/central -o sec=krb5
mount.cifs: permission denied: no match for /home/CauserC/central found in /etc/fstab

# Sudo mount.cifs with/without suid root
$ sudo mount.cifs //server/share/directory ~/central -o sec=krb5
mount error(126): Required key not available

I do definitely have a kerberos ticket, and both klist and "sudo klist" show it to me.

Now, it does work if I do a "sudo kinit $USERNAME." Then a sudo mount.cifs mounts the share no problem. This is obviously less than ideal because it involves typing in a password again, and subsequent non sudo klists result in:

$ klist
klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_10009_8ZePnt)

I'm tempted to file this as a bug report but wanted to check in here first to make sure that I'm not doing anything stupid. As I say, I never tried this in Lucid as suid root worked fine.

Any help appreciated

Chris

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: smbfs 2:4.5-2
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic-pae 2.6.35.4
Uname: Linux 2.6.35-22-generic-pae i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Wed Nov 17 15:20:14 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: cifs-utils

[ChrisCauser (chy-causer)]

Looking at the source and although I haven't tested it:

Line 1597:
 if (getuid()) {
  rc = check_fstab(thisprogram, mountpoint, orig_dev,
     &orgoptions);
  if (rc)
   goto assemble_exit;

  /* enable any default user mount flags */
  parsed_info->flags |= CIFS_SETUID_FLAGS;
 }

If the conditional were changed to geteuid(), then running mount.cifs as suid root would not result in an fstab error. Obviously I'd rather not do that and work with sudo if at all possible.

[Anthony (inolen)]

Did you ever find a solution to this? I'm currently experiencing the exact same problem on Lucid.

[Anthony (inolen)]

To add a little more, I've noticed that executing the sudo kinit $USER isn't essential as I thought it was. If I just sudo chmod root:root <ccache_file> the mount works fine as well.

So:
user> kinit
user> sudo mount.cifs //host/share /folder -o sec=krb5
mount error(126): Required key not available
user> sudo chmod root:root /tmp/krb5cc_1000_XWHnic
user> sudo mount.cifs //host/share /folder -o sec=krb5
success

[ChrisCauser (chy-causer)]

'Fraid not Anthony. Thanks for the tip with with the chown. To be honest, suid worked for me so I just lived with that. Later versions past Lucid don't work that way unfortunately. I'll have to see what happens when 12.04 comes out :)

[Garen (garenp)]

I noticed that pam_krb5 sets:

 $KRB5CCNAME to /tmp/krb5cc_<uid>_<six-random-chars>

Which can cause the "Required key not available" error because mount.cifs is actually looking for a per-uid, not per-session file at /tmp/_<uid>.

Not yet found a way around it, but to mount things manually I have to do e.g.:
$ sudo cp /tmp/krb5cc_<1234>_<blahblah> /tmp/krb5cc_<1234>

After that, mount commands with "-o sec=krb5" actually works. Some background info here:

https://bugzilla.redhat.com/show_bug.cgi?id=517195

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Cornelius Hald (hald)]

Just wanted to confirm that the behavior described in comments #1 to #5 is still present on Ubuntu 12.04.1 LTS. However I cannot see the behavior described in comment #6. For me $KRB5CCNAME holds the correct path to the file and the file is in the form /tmp/krb5cc_<uid>.

To me it looks like "sudo mount.cifs" finds the correct file, but does not use it because it does not belong to root.

[ikitomi (kidatsuda)]

anybody know ? This bug solved in Ubuntu 13.0?

[Pietro Cerutti (gahr)]

I'm using the chown root $KRB5CCNAME trick too in 12.04, but this results in the ticket not being refreshed.
After a short time, the mount point becomes inaccessible. Trying to ls into it gives: Required key not available.

[mcguire (jonathand131-gmail)]

Hi,

I had the same issue today and finally found a solution.
The problem is with the kerberos ticket file ownership.
When mount is called using sudo, cifs.upcall searchs for a cache file owned by root.
Using the cruid option when calling mount.cifs, you can specify the ownership to search/use.

Here is my command :
/usr/bin/sudo -- /sbin/mount.cifs //my-server/my-share /my/mountpoint -o uid=$( id -u ),gid=$( id -g ),sec=krb5,cruid=$( id -u )

Hope this helps.

(Tested on Ubuntu 12.04.3 LTS)

[mcguire (jonathand131-gmail)]

Not a bug a bad mount.cifs usage.

[DG Turner (d-turner)]

Regarding the comment from mcguire on 2014-03-12
>>Not a bug a bad mount.cifs usage.
>>
>>Changed in cifs-utils (Ubuntu):
>>status: Confirmed → Invalid

What is wrong with you? This is a critical bug, not invalid usage. By forcing users to impersonate themselve from the SUDO command, you subvert the entire purpose of the kerberos system -- authentication.

[DG Turner (d-turner)]

Marking this as invalid was either an error, or a misunderstanding of the underlying mechanisms and purpose of kereros.

[mcguire (jonathand131-gmail)]

From what I have understood of the bug description, the original poster is looking for a way to mount a remote network share using cifs and its kerberos ticket as credential to authenticate on remote server.

The mount command requires root privileges so must be called as root in some way. This could be achieved using sudo or using suid. From my point of view, nothing kerberos related here.

The command line I have suggested to use in comment #11 does this: use sudo to run mount as root and use the already acquired kerberos ticket to authenticate on remote server to access cifs network share.

Also, I understand that what have changed is that it used to works with the user kerberos ticket before Meerkat release without any tricky option.
Probably that in version prior to Meerkat, cifs-utils what not restricting its credential ticket search based on ticket file owner.
However, the owner match can be configured using the uid option or cruid option for cifs-utils >=4.8) so there is a simple way to allow the use of the user owned kerberos ticket file.

As you pointed, I could be wrong in my understanding, so please tell me on which point.

[ChrisCauser (chy-causer)]

To mcguire:

I haven't been updating this bug report as my circumstances have changed, but I'll just chip in with my thoughts.

The mount options you specify (specifically cruid) look like they are there specifically to solve the issue, and they most definitely were not around for the Maverick release of mount.cifs when I filed this report. To my eyes it looks like quite inelegant, not least because sudo passes all the relevant information for mount.cifs to use in the first place so it shouldn't be needed at all, but if it works, then who am I to complain?

[DG Turner (d-turner)]

Kerberos' purpose is authentication. More verbosely, using kerberos as the primary authentication method should ensure that the presented credentials do in fact belong to the user presenting them (whether that is a real user or a service is irrelevant).

To force the impersonation of credentials to perform a mount of a Windows share within the user's home directory is a subversion of the kerberos mechanism, and potentially allows a breach to propagate.

The concerns raised by this behaviour may raise fewer alarm bells for those more accustomed to a *nix environment. When the environment is Windows/Active Directory based, the aforementioned concerns become much more disconcerting. The potential damage caused by the impersonation of a user by root could be catastrophic is the right user were impersonated, which is why several of my systems are configured to send an alert when a chown of any ticket is attempted.

To make matters more interesting (at least for me), the cruid option still fails for me when attempting a mount using kerberos credentials.

[Penelope Fudd (login-launchpad-net-x)]

I think I see the source of the problem....

When I do this:

# sudo strace -fo/tmp/a -p $$ &
# sudo mount -t cifs -o username=me,rw,uid=me,gid=mygroup,port=445,sec=krb5,creduid=/tmp/krb5cc_1000 \\\\server.example.com\\home\\me /mnt/me
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
# kill %1
# grep krb5cc /tmp/a
8619 access("/tmp/krb5cc_1000", R_OK) = 0
8619 open("/tmp/krb5cc_1000", O_RDONLY) = 3
# grep ' mount(' /tmp/a
8618 mount("\\\\server.example.com\\home\\me", ".", "cifs", 0, "ip=1.2.3.4,unc=\\\\server.example."...) = -1 EINVAL (Invalid argument)
# dmesg | grep CIFS
[ 4634.121902] CIFS: Unknown mount option "creduid=/tmp/krb5cc_1000"

When I don't used 'creduid=', the mount command returns:
   mount error(126): Required key not available
   Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
and the strace output shows that it doesn't try accessing /tmp/krb5cc_* at all.

When I instead try 'cruid=1000', the same error occurs, and again, no /tmp/krb5cc_* files are being accessed.

In short, I think that either the cifs kernel module needs to allow the creduid option, or the mount.cifs program needs to strip it out before calling mount(). After that, I don't know what else has to happen; perhaps both creduid= and cruid= need to be specified? Or perhaps creduid= needs to be renamed to kccf= (kerberos cached credentials file, a name pulled out of a hat)?

Hopefully someone finally makes cifs+kerberos work from /etc/fstab or /etc/pam.d so that it can be mounted when I log in, without having to enter my password again.

Thanks!