[PATCH] documentation fixes and keytab handling regression

[Jeremy Allison]

On Sat, Dec 03, 2016 at 08:37:58AM +0200, Alexander Bokovoy wrote:
> > 
> > I want to understand what you're trying to
> > do here before we make code changes.
> As I said, I'm trying to fix the regression -- Fedora 25 with Samba
> 4.5.x now broke FreeIPA deployments.
> 
> Looking at smb_krb5_kt_open_relative() and smb_krb5_kt_open(), though,
> I'm not sure what's the purpose of the whole '/' check in
> smb_krb5_kt_open() -- had it not be there, smb_krb5_kt_open_relative()
> would equally do the justice and only accept absolute paths to WRFILE:
> and FILE: prefixed keytabs already.
> 
> I'm not really sure why it is named _relative(), though. There is
> nothing there for relative paths at all. If you passed the keytab name,
> it gets analyzed whether it is prefixed with WRFILE:/ or FILE:/ and if
> not, either FILE: or WRFILE: is prepended to the path and then keytab
> gets open. In the latter case the keytab name is obviously relative.
> 
> It would also break for MEMORY: keytabs, as that case is not handled
> right in the code path for when the keytab name is passed in.
> 
> If you don't pass the keytab name, _relative() does try to obtain the
> name of the default keytab and parse it. Here it expects all kinds of
> prefixes but there is nothing for the 'relative' paths there either. 
> 
> It seems to me that smb_krb5_kt_open() refactoring would be to eliminate
> the distinction between the two as it is not simply useful at all.

That sounds good to me. git-blame shows Andreas created this
code (I love that command :-).

Can you check with him (CC:ed) and once we've worked out
exactly what we're trying to do with this code we can
work on a proper patch. It's incoherent right now.

Cheers,

	Jeremy.