6

I have configured autofs on CentOS using /etc/auto.mymount. Something like this:

mymount -fstype=cifs,rw,noperm,credentials=/etc/auto.creds.svc_account ://winserver.domain.local/SharedFolder

This has been working and still does for some mounts. However a password has been changed for an account which is used for connecting to a Windows server and this now contains all sorts of special characters. My credentials file /etc/auto.creds.svc_account looks a bit like this:

username=svc_account
password=AbCd@a;abc{`B"[C\\~/fg9w(G':4##abC}d3.H}v,2]f+c

Obviously I have changed the password above, but it does contain various non alpha-numeric characters that are in the real password.

Looking in /var/log/messages, I see the following:

Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13

Given that the only thing which has changed is the password, I'm guessing that that there are special characters in there which need to be escaped somehow.

Now I know that if I put that password into the command line, then commands will fall over due to the various special characters, which can be dealt with by preceding each of them with a backslash. For instance:

password=AbCd@a\;abc{\`B\"[C\\\\~/fg9w\(G\':4##abC}d3.H}v,2]f+c

But that didn't work, so clearly I'm missing something. Is anybody able to explain which characters need to be escaped in a credentials file and the correct way to escape them?

Steve
  • 121
  • 1
  • 7
  • Did you try variations of the format in a credentials file, where the password is alphanumeric? It may be easier to figure out the correct format that way? A few modifications worth trying when the password is alphanumeric would be to add single- or double-quotes around the password. Put a backslash before a single character, which doesn't usually have special meaning when escaped. Knowing if any of those works, may help figure out the correct escaping. – kasperd May 20 '14 at 12:23

4 Answers4

6

I suppose the credentials file will be read by mount.cifs, like for other CIFS mounts. So I had a look at the mount.cifs.c source file in the current cifs-utils code, which should be for version 6.3. The code for reading the password does no unescaping, except that every comma is doubled in the password field of the parsed_mount_info struct, as is apparently necessary when assembling the parameters for the mount(2) call:

/*
 * CIFS has to "escape" commas in the password field so that they don't
 * end up getting confused for option delimiters. Copy password into pw
 * field, turning any commas into double commas.
 */
static int set_password(struct parsed_mount_info *parsed_info, const char *src)
{
    char *dst = parsed_info->password;
    unsigned int i = 0, j = 0;

    while (src[i]) {
        if (src[i] == ',')
            dst[j++] = ',';
        dst[j++] = src[i++];
        if (j > sizeof(parsed_info->password)) {
            fprintf(stderr, "Converted password too long!\n");
            return EX_USAGE;
        }
    }
    dst[j] = '\0';
    parsed_info->got_password = 1;
    return 0;
}

In case of a credentials file, src points to the position in the password line just behind the = sign. Everything between the = sign and the end of the line as read by fgets() is copied into the password field. (The newline is replaced by a null byte before copying.) But for every other way to set a password, like environment variables, options, or from stdin, the same routine is called, so if mounting the volume works from the command line, that comma doubling is not the culprit.

However, you might get into trouble if any line contains trailing whitespace or your credentials file has non-UNIX line endings. A trailing CR would be read as part of the password, as would other trailing whitespace. Similarly reading the password could fail if your password contains any non-ASCII characters, where the encoding of the file would be important.

TL,DR:

  • Nothing has to be escaped in the password
  • Check if mounting the CIFS volume works from the command line
  • Check for trailing whitespace in the password line
  • Check if your credentials file has UNIX format and no DOS line endings
  • Check for non-ASCII characters (like umlauts) in the password
  • Check if it works with a password without commas (it really shouldn't make a difference, but who knows)
Dubu
  • 611
  • 3
  • 12
  • 1
    Am I the only one thinking there is a buffer overflow in that piece of code? – kasperd May 20 '14 at 17:24
  • @kasperd You are probably right. If the password is exactly `sizeof(parsed_info->password)` bytes long, the appended null byte would be written beyond the field length. (Similar if the password is `sizeof(parsed_info->password)-1` bytes long and the last character is a comma.) – Dubu May 20 '14 at 18:25
  • Thanks for the details on mount.cifs. As I'm not an Active Directory admin I had a go at changing my personal Windows password to include a comma. I was able to mount the drive using my personal account. I'm guessing that perhaps there's another character which **should** be getting escaped by mount.cifs, so I think I'll have a go at changing my password to include them, one at a time, and see what happens. :) – Steve May 21 '14 at 15:37
  • @Steve Thanks for the bounty, but did that solve your problem? What did you do? – Dubu May 28 '14 at 05:28
  • It was well worth the bounty, so that was a thank you for the effort. Unfortunately it didn't solve the problem. So I'm changing my personal password (the only A/D password I'm able to change) to include a new non-alphanumeric character every few days (domain policy prevents more frequent) until I find the character which causes the problem. Assuming that I find such a character, I'll update here. – Steve May 28 '14 at 08:19
1

Do you possibly have any spaces in the file, perhaps between the = signs? a -13 error can be caused by spaces in the creds file, as per the following link. http://thinkinginsoftware.blogspot.com/2011/09/cifs-vfs-cifsmount-failed-return-code.html

My own thinking also wonders if this might be due to an encoding issue with the file itself. What does file -bi /etc/auto.creds.svc_account return? Perhaps there is a stray control character? What does opening the file with vim and running :set list show? Perhaps it wasn't an issue before because the encoding used only "blows up" on certain characters which were not present in the password until now. The easiest way to troubleshoot this would be to recreate the file and try again, or compare the old working password with the new one and determine what new special characters may have been introduced.

usedTobeaMember
  • 616
  • 15
  • 25
  • There are no spaces. `file -bi /etc/auto.creds.svc_account` gives me: `text/plain; charset=us-ascii`. Unfortunately, the previous password was just alphanumeric. **All** of the non-alphanumeric characters in the example password above were introduced. :) – Steve May 21 '14 at 09:06
  • What about opening the file with vim and trying :set list? Any control characters where you wouldn't expect them? – usedTobeaMember May 21 '14 at 13:02
  • Nothing other than the `$` characters that it shows for line endings. – Steve May 21 '14 at 15:39
  • Try moving the password back into fstab and see if it makes a difference, just temporarily. If it works in fstab, recreate a credentials file in /etc with 0600 permissions and see if that works. If it doesn't work in fstab, just choose a different password and make your life easier. – usedTobeaMember May 25 '14 at 16:06
1

I don't know if this is way too late to answer this, but for anybody else having this issue, I just spent a couple of hours banging my head against a wall with a CentOS6 VM trying to access cifs shares on the Windows 7 host.

In the end, what worked for me was changing the password line in the credentials file to use "pass" as the parameter name. e.g.

user=myUserName
domain=MYDOMAIN
pass=myStrongPasswordWithSpecialCharacters

I don't know if something about the special characters in the password screwed something up when the file was parsed, but I noticed that username and password were being parsed to user and pass, so decided to cut that step out by putting those values directly in the file.

Hope this helps somebody.

jackos
  • 11
  • 1
0

You should be able to use octal ASCII codes for special characters, e.g.:

SPACE = \040
AMPERSAND = \046

Consult ASCII table here: http://www.asciitable.com/

Solution found on: http://www.linuxforums.org/forum/ubuntu-linux/175662-solved-fstab-special-characters.html

akaihola
  • 164
  • 8
phoops
  • 2,073
  • 4
  • 18
  • 23