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...

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