maindavfs2 - Support: sr #108675, Mount with autofs and Kerberos

 
 

sr #108675: Mount with autofs and Kerberos

Submitter:  None
Submitted:  Tue 28 Oct 2014 09:55:35 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  In Progress
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 06 Nov 2014 08:40:37 PM UTC, comment #4: 

"Is it easy for you to implement an option that I might pass from autofs to change the effective user-id of mount.davfs"

This would not be too difficult. But before doing it I would ask you to check whether it will do the trick:

As I understand you have already set up Kerberos for at least one user. When this user mounts manually then Kerberos authentication will work. Could you please test what happens when you

  • set option "dav_user" to this user
  • not set the uid option in autofs

Will authentication then work (it probably depends on whether GSSAPI uses the real or the effective user-id).

If it does not work, it will get more complicated but could be done.

If it works then there are two options:

  • davfs2.conf knows mount point specific setctions (see man davfs2.conf). If you use a different mount point for each user (you probably do) then you can set option dav_user in moint point specific sections for each user differently and are done.


  • davfs2 could be changed to accept option dav_user from the command line. So you could set it in the autofs configuration. I would do this if you convince me that it is important not to have to edit two different config files for every user.


As said above, it depends on the outcome of the test.

Werner

- <_71007>
Wed 05 Nov 2014 09:46:24 PM UTC, comment #3: 

Thank you for this information! I will have a deeper look into the individual user contexts of the individual components.

I am afraid that none of the solutions you suggest are suitable: If I would set up a valid kerberos session for user davfs2 (or whatever I configure in davfs2.conf), any mounting would be done in that context. My goal however is to have the automounting done in the context of the individual user, i.e. if more than one user mounts a WebDAV-share on the same system (at individual mountpoints), each should access it with his permissions. Such a configuration is possible e.g. using mount.cifs (for SMB/CIFS shares), where in some way the current user context is passed to the mounting system (an entry in the automount-map would look like

mountpoint -fstype=cifs,sec=krb5i,uid=$UID ://<FQDN>/<Share>

). I will try to find out how they do it - perhaps that hints me on what to do with mount.davfs. What I already know is that mount.cifs somehow works with RPC upcalls... But if I remember correctly, this is just its way to implement GSSAPI, which in the davfs-case is the neon-library.

Just to have asked: Is it easy for you to implement an option that I might pass from autofs to change the effective user-id of mount.davfs (like uid=$UID, but not changing the owner but the effective user and/or the real user)? If I understand you correctly, that might already do the trick...

Anonymous
Sat 01 Nov 2014 10:13:01 AM UTC, comment #2: 

Additional comment:
The mount option uid= has no effect on this all. It only sets the owner of the file system (locally) but does not affect the uid of the running mount.davfs daemon and does in no way affect authentication.

- <_71007>
Sat 01 Nov 2014 10:06:55 AM UTC, comment #1: 

Thanks for this report about a working Kerberos authentication. I have no access to an Active Directory or any other Kerberos server and can't test it myselft. This is the first time I hear of Kerberos authentication working at all.

Some background:
davfs2 is not directly involved in Kerberos authentication. It is done by the Neon library which in turn delegates it to GSS-API. When a server requests Kerberos authentication the GSS-daemon will have to decide which credentials to use. As far as I understand this decision is based on the user-id of the mount.davfs process. I don't know whether the real user-id or the effective user-id of the process is used. Using the effective user-id would be better for davfs2.

For mounting mount.davfs needs root privileges and therefore is usually run setuid root. It will use these priveleges only when necessesary and after mounting get rid of them alltogether (for security reasons).

There are two different situations:

  • A nonpriveleged user mounts: when accessing the server the  real user-id and the effective user-id of mount.davfs will be that of the mounting user. This is the case where Kerberos authentication works.


  • root mounts: This is probably the case with autofs. When the server is accessed for the first time the real user-id is root and the effective user-id is davfs2. After mounting the real and the effective user-id will be davfs2. You probably have not set up Kerberos for root and for user davfs2. So authentication fails.


How to get it working?
I can't test it myself, so I can only propose possible solution. I'm not sure whether any of this will work.

  • If autofs would mount not as root but as the same user you used in example 1, it should work. But I think this will not be possible with autofs.


  • Set up Kerberos for user davfs2 or, alternatively, set option "dav_user" to the user you used in example 1. You must do this in the system wide davfs2.conf file (not in the user's davfs2.conf file). This should work if the gss-daemon uses the effective user-id, but will fail if it uses the real user-id. The reason is that the first access to the servers happens before the real mounting.


If this does not work I could prepare a patch that skips the first access to the server and only starts HTTP-traffic after the file system is mountd when real and effective user-id are the configured dav_user.

You can additionally use debug options "config" and "httpauth" to get more information about what is going on (please see man davfs2.conf for details).

Werner

- <_71007>
Tue 28 Oct 2014 09:55:35 PM UTC, original submission:  

Dear all,

I try to use autofs to automount a SharePoint document library using Kerberos SSO. I have...

  • A working Kerberos setup (user can login with Windows Active Directory credentials and get Kerberos tickets)
  • A successful configuration using /etc/fstab:


/etc/fstab contains:

http://server/path/to/webdav /mountpoint/webdav davfs noauto,user,rw 0 0

/etc/davfs2/davfs2.conf contains:

ask_auth 0

/etc/davfs2/secrets is unmodified/empty, as well as ~/.davfs2/davfs2.conf.

--> Kerberos user logs in, and issues:

mount /mountpoint/webdav

and under the hood the Kerberos service ticket is acquired and without any further user input the SharePoint library ist mounted. Viola, so far, so good, but now I change the game, no entry in /etc/fstab, but:

/etc/auto.master contains:

/mountpoint /etc/auto.webdav

/etc/auto.webdav is:

webdav -fstype=davfs,rw,uid=$UID :http://server/path/to/webdav

Kerberos user logs in, issues:

cd /mountpoint/webdav

and gets "no such file or directory". Switching debug to "httpauth" brings up in /var/log/syslog:

No Kerberos credentials available

Obviously, the mout.davfs does not access the Kerberos credentials of the mounting user, although a valid TGT is available. Even when I have valid service tickets from the prior test using fstab, acces does not work.

Can you help?

Thanks!

Kind regards

Caerandir


Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-15 _71007 Open/ClosedOpen Closed
    2014-11-01 _71007 StatusNone In Progress
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code