helpdavfs2 - Support: sr #107927, davfs2 does not trust self-signed...


sr #107927: davfs2 does not trust self-signed certificate... with a twist

Submitted by:  None
Submitted on:  Mon 02 Jan 2012 12:38:33 PM UTC  
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  Werner Baumann <wbaumann>
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 20 Apr 2014 06:26:41 PM UTC, comment #10:

The certificate related problems as well as the mtab related problems are now solved in the CVS sources branch MAIN and branch rel-1-4-6.

Note: to solve the mtab related problems davfs2 relies on newer functionality of the mount program like the utab file and the helper option. I don't know whether this is available on uClib based NAS systems.


Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Mon 09 Jan 2012 12:29:41 PM UTC, comment #9:

I've fixed fstab for uClibc in the uClibc portability issues ticket

The system is just a NAS, so there are no problems with permissions (for me). Of course this is not acceptable under normal circumstances.

Tomi <tomi>
Sat 07 Jan 2012 08:09:29 PM UTC, comment #8:

umount and fstab issues:

As your system has no fstab mount will not allow unprivileged users to mount at all (unless you are using a patched version of mount). So you are probably invoking mount.davfs directly (it is intended to be a mount helper).
The patch you mentioned removes davfs2's check for fstab. Please be aware that this removes most of davfs2 security checks for user mounts. A unprivileged user will now be able to mount anything almost anywhere, including crucial system directories. davfs2 does not require that the user owns the mount point. The guys that did this patch should have patched the mount.davfs man page as well. It makes security promises that are no longer true.


I don't know whether umount will work for unprivileged users without fstab. If you invoke umount.davfs directly you must know that it is more or less a wrapper and invokes umount to do the real unmounting. So restrictions set by umount will apply. umount.davfs is not setuid root. If option 'users' does not work you will probably have to make umount.davfs setuid root.

With these changes every user will have root privileges with respect to davfs2 mounts. Making umount.davfs setuid root might even enable an unprivileged user to umount other file systems (I have not verified this but clever people should be able to exploit it).

Do you really need user mounts? It might be easier to remove the setuid bit from mount.davfs and use root priveleges for mounting. At least it would remove a lot of risks. Maybe something like sudo could be used to give users the right to mount in a controlled way.


Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Fri 06 Jan 2012 08:08:49 PM UTC, comment #7:

The davfs2 man page for option 'servercert' is wrong.
I made a stupid mistake in interpreting a Neon function used for this. Indeed you cant provide a certificate chain at all but only one CA-certificate, usually the certificate of the top-level CA. That's why it works when the top-level CA is the first in the file but fails when it is the last one.

I will change this in the next version and will most probably provide quite another option which should better solve most problems. This would be an option to provide the server certificate (not a CA-certificate) and will only check whether the certificate presented by the server is identical to the one configured (without checking all the other niceties like validity date, server name and the like).


Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Thu 05 Jan 2012 07:27:46 PM UTC, comment #6:

I found the problem and solved it!
I am not sure if I can't read properly; davfs2.conf says the following:
"If an hirarchy of CA's is involved (the CA that signed the server certificate is not the root CA), the file must contain all the certificates from the chain of CAs involved, beginning with the CA that signed the server certificate, up to the self-signed certificate of the root CA. (The option name servertcert is a misnomer in this case. Sorry.) You can create the file by concatenating all the CA-certificates involved."

Now I didn't do anything, just followed a guide on the internet that retrieved this chain for me from Firefox. The chain of certificates were the following:
Issuer: Google, Subject: *
Issuer: Equifax, Subject: Google
Issuer: Equifax, Subject: Equifax

I took this as correct, especially after reading the configuration for the dozenth time.
However, it should be in the opposite! order. Thus starting with the root CA and having a trusted chain all the way down to the domain.
Issuer: Equifax, Subject: Equifax
Issuer: Equifax, Subject: Google
Issuer: Google, Subject: *

Everything worked after this. The error message makes sense as well now; At that point Google is not signed, and thus not trusted. Why did things work without servercert? All the certificates in etc/ssl/certs are in different files, thus libneon picks them at will... I presume.

Tomi <tomi>
Tue 03 Jan 2012 08:53:35 PM UTC, comment #5:

I know how free software works, I've worked in it for years. However, I was under the impression that it was a classic user mistake (which was solved by installing the CA certificates) and thus not a davfs2 problem. To be honest I have no knowledge of SSL, certificates, etc, and thus was more than happy when I got it working.

But if it were supposed to work with the original configuration I'll help you find my issue :)

So. I've removed all the certificates in etc/ssl trying to mount the share gives the following:
/sbin/mount.davfs: the server certificate is not trusted
issuer: Google Inc, US
subject: Google Inc, Mountain View, California, US
identity: *
fingerprint: aa:c7:11:ed:d8:09:b5:42:49:29:e4:45:e5:f6:23:af:de:e2:ef:01
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N] y
/sbin/mount.davfs: warning: the server does not support locks

syslog is attached.

For unmounting all I get is the following; nothing in syslog
tomi@alexandria:/$ umount /mnt/gmail
umount: only root can unmount from /mnt/gmail
It might not work because uClibc doesn't support /etc/fstab, so I've used the patches from:
mainly so if that is the cause of my problems then I'm fine with it.

(file #24732)

Tomi <tomi>
Tue 03 Jan 2012 07:58:15 PM UTC, comment #4:

"That was the only error message I had."
If you get message "/ffp/sbin/mount.davfs: the server certificate is not trusted. " you will also get messages starting with "issuer:", "subject:", etc. unless you redirect stdout but not redirect stderr. But if you redirect stdout you will not be able to accept the certificate.

If the certificate is accepted after you installed the CA-certificates there is still something severely wrong. The servercert file you configured contains the whole certificate chain, so it should work too. If it doesn't it would be worth to look what is going wrong. That's why I suggested 'debug config'.

Your mtab file does not work the standard way. The line in your mtab is just a copy from /proc/mounts. But davfs2 writes the mtab entry by its own and it looks quite different. So writing the mtab entry failed. As davfs2 opens mtab explicitly for append writing must not fail or davfs2 must get an error on openening. In this case davfs2 would print an error messages. Either you did not see or report this error messages or there is a bug in your system (allowing open append but not allowoing append) or your davfs2 sources have been changed by somebody.
(davfs2 only checks for an error when opening mtab. It should additionally check for an error on writing the entry. I will change this in future versions.)
The problem: umount will check mtab for the id of the mounting user. But the /proc/mounts entry does not have this information. That's why umount does not allow unmounting by an unprivileged user. There is no way in the interface of the fuse kernel module to pass on this information in order to have it included in /proc/mounts. (Maybe this has been changed in recent releases of fuse. I will have to check for this. But updating to an newer fuse interface would require a lot of additional changes.)

Some remark on how free software works.
While devolpers of free softwork offer their software to you for free and also offer free support you could and should take your share in free software development. Your support requests and bug reports help to improve the software for the benifit of all. But if your interest in fixing the problem ends as soon as it "works for you" but before the reason for the problem is found and before I am able to fix it for all users, then I don't know why I should spend my free time to solve "your" problems.


Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Tue 03 Jan 2012 09:48:37 AM UTC, comment #3:

That was the only error message I had. I've ran debug ssl and didn't see anything wrong in syslog, of course I should not be the one to judge that :)

The strangest thing was that davfs2 worked correctly on another machine as I've said with exactly the same configuration and parameters. I've started digging a bit deeper and found the source of the problems after your comment of "So there might be something wrong or missing with your OpenSSL installation."

This was exactly the case. Apparently OpenSSL doesn't supply CA certificates anymore, so I've had to download[1] and install them them myself. The ubuntu distribution I've been using was shipped with certificates. Thank you for pointing me in the right direction.

Concerning mounting: my mount line is from "mount"
/proc/mounts: /mnt/gmail fuse rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=100,allow_other,max_read=16384 0 0
/etc/fstab: /mnt/gmail davfs noauto,user 0 0
/etc/mtab: /mnt/gmail fuse rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=100,allow_other,max_read=16384 0 0

I will try the option users in /etc/fstab but it should not be needed as I have an /etc/mtab file - which is why I picked user in the first place. The only unmount error message I had is about "only root can unmount". I will try with the users option.


Tomi <tomi>
Mon 02 Jan 2012 08:41:26 PM UTC, comment #2:

Please include all and complete error messages from davfs2. (I'm tired of asking for this over and over again. Why do you think it helpful to truncate error messages?)

You may set options 'debug config' and 'debug ssl' to your davfs2 config file. Your log files will then contain debug messages from mount.davfs showing your configuration (did davfs2 find the cert file?) as well as messages from neon concerning TLS/SSL.

This isn't a self-signed certificate. The CA-certificate of Equifax Secure Certificate Authority is usually included in the systems certificate data base. So there might be something wrong or missing with your OpenSSL installation.

When an unprivileged user can mount but not unmount this is probably due to problems with /etc/mtab (/etc read-only?). (Your mount line is from /proc/mounts not from mtab?) Wasn't there an error message along the line "Warning: can't write entry into mtab, ..."?. Adding option 'users' instead of 'user' in fstab should work around this. Please also look at 'man mount.davfs' for these options.

"davfs2 v1.4.6 compiled from scratch for ARM with openssl-1.0.0d."
I'm not sure whether I understand this correctly, but in case there is a misunderstanding: davfs2 does not link against any SSL-library and there is no option in configure for SSL. davfs2 links against libneon and only neon will call functions from the SSL-library.


Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Mon 02 Jan 2012 12:56:42 PM UTC, comment #1:

My apologies, did not log in.

Tomi <tomi>
Mon 02 Jan 2012 12:38:33 PM UTC, original submission:

I have basically the same problem as has been brought up here:

davfs2 v1.4.6 compiled from scratch for ARM with openssl-1.0.0d. I have the following problem:
/ffp/sbin/mount.davfs: the server certificate is not trusted.

WEBDAV URL: on /mnt/gmail type fuse (rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=100,allow_other,max_read=16384)

servercert *

/mnt/gmail <user> <pass>

servercert in text form (openssl x509 -in <filename> -noout -text) is attached. With or without servercert I have to manually accept the certificate. However, I have a virtual machine running some ubuntu version with davfs2 v1.4.6 as well. Same setup (eg same davfs2 configuration files, pem, etc.) and there it works?

Could you maybe shed some light on what might be wrong?

(second minor issue: I can mount as user, but not unmount as user?)



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #24732:  syslogd.log added by tomi (11KiB - application/octet-stream - attached syslog with debug config, ssl)
file #24721: added by None (2KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by wbaumann (Posted a comment)
  • -email is unavailable- added by tomi (Posted a comment)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    Sun 20 Apr 2014 06:26:41 PM UTC wbaumann StatusIn Progress => Done
        Open/ClosedOpen => Closed
    Tue 03 Jan 2012 08:53:35 PM UTC tomi Attached File- => Added syslogd.log, #24732
    Mon 02 Jan 2012 08:41:26 PM UTC wbaumann StatusNone => In Progress
        Assigned toNone => wbaumann
    Mon 02 Jan 2012 01:00:22 PM UTC tomi Attached File- => Added, #24722
    Mon 02 Jan 2012 12:38:33 PM UTC None Attached File- => Added, #24721

    Back to the top

    Powered by Savane 3.3