maindavfs2 - Support: sr #107800, Permission checking on client...

 
 

sr #107800: Permission checking on client certificate files is unnecessarily too strict

Submitter:  None
Submitted:  Wed 14 Sep 2011 04:25:55 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  _71007
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 19 Jul 2012 05:33:55 PM UTC, comment #4: 

I believe version 1.4.7 fixes this bug.

Werner

- <_71007>
Tue 20 Sep 2011 06:57:09 PM UTC, comment #3: 

Ref.: your email from 2011-09-019

Yes, root-squashing by NFS is not taken into account by davfs2, so at the moment a client certificate on a NFS file system with root-squash can not be read.

But changing the file permissions of the client certificate is the wrong way to deal with this.

The bug is in file webdav.c, function dav_init_webdav, and looks like this:

        if (args->clicert) {
            uid_t orig = geteuid();
            seteuid(0);
            ne_ssl_client_cert *client_cert
                    = ne_ssl_clicert_read(args->clicert);
            seteuid(orig);
            if (!client_cert)
                error(EXIT_FAILURE, 0, _("can't read client certificate %s"),
                      args->clicert);

davfs2 allways uses id 0 to read the certificate. The  proper way would be to use root privileges only for certificates in the system configuration directory and use the id of the mounting user in all other cases. I will open a bug tracker item for this.

Meanwhile a quick workaround would be to first try without root privileges and only when this fails switch to id 0:

        if (args->clicert) {
            ne_ssl_client_cert *client_cert
                    = ne_ssl_clicert_read(args->clicert);
            if (!client_cert) {
                uid_t orig = geteuid();
                seteuid(0);
                client_cert = ne_ssl_clicert_read(args->clicert);
                seteuid(orig);
            }
            if (!client_cert)
                error(EXIT_FAILURE, 0, _("can't read client certificate %s"),
                      args->clicert);

Please note: one of the first actions of davfs2 is to change the effective user id from 0 to that of the mounting user. You will find commands to switch the user id only to temporarily gain root privileges, not the other way round. Checking file permissions of a client certificate in the user's home directory is done with the id of the mounting user.

Cheers
Werner

- <_71007>
Thu 15 Sep 2011 07:22:24 PM UTC, comment #2: 

And another point:

When davfs2 is setuid root and is started by <user> the running process has two identities: root and <user>. Moreover: it can switch between these two identies. It can act with root priveleges and it can act with the permissions of <user>. At start up davfs2 will do some of this switching: most of the time it will act as <user> and only when necessary it will temporarily act as root.

Finally when the file system is mounted it will discard root privileges unrevocably and only run with the identity of <user>.

Werner

- <_71007>
Thu 15 Sep 2011 07:01:03 PM UTC, comment #1: 

Well, root can read everything (as long as we deal with Unix file permissions) and as davfs2 will start with root permissions (it would not be able to mount anything without them) it is able to read the client certificate of every user.

Do you have any real problems with davfs2 reading a client certificate stored in the user configuration directory or is this just a misunderstanding regarding the man page text?

This error is treated as an fatal error and not as a warning because a private key that is not private is useless.

Werner

- <_71007>
Wed 14 Sep 2011 04:25:55 PM UTC, original submission:  

The davfs2.conf man page describes how client certificates can be stored in the users home directory:

"The name of the file may be given as absolute path or as file name only. In the latter case the directories ~/.davfs2/certs/private and /etc/davfs2/certs/private will be searched."

If the client certificate is stored in ~<USER>/.davfs2/certs/private mount.davfs will check at startup that the certificate file is only readable by <USER>.

But now there's a problem if a davfs mount point was configured in /etc/fstab such that ordinary users can mount it. One the one hand, mount.davfs will check at startup that the certificate file is only readable by <USER> and issue an error otherwise. One the other hand, mount.davfs has to be 'setuid root' (at least on Debian/Ubuntu) but if it starts as root, it can not read the client certificate (which is only readable by <USER>) anymore.

So I would suggest to turn the error "client certificate file %s has wrong permissions" into a warning (as in the attached patch). Or are there other, beetter workarounds for this problem?

Thank you and best regards,
Volker

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #23974:  client_certificates.patch added by None (564B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-07-19 _71007 StatusReady For Test Done
        Open/ClosedOpen Closed
    2011-09-20 _71007 StatusNeed Info Ready For Test
    2011-09-15 _71007 StatusNone Need Info
        Assigned toNone _71007
    2011-09-14 None Attached File- Added client_certificates.patch, #23974

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code