[OpenAFS] Changed behaviour (?) in client kernel module.

Anders Magnusson ragge@ltu.se
Tue, 02 Dec 2014 15:42:03 +0100

Marc Dionne skrev den 2014-12-02 12:33:
> On Mon, Dec 1, 2014 at 12:37 PM, Anders Magnusson <ragge@ltu.se> wrote:
>> Some years ago (around 2008) I did setup a SMB to AFS gateway like this (on
>> RedHat):
>> - samba configured to use Kerberos for client auth
>> - when user authenticated, use root preexec with kimpersonate to get an AFS
>> token
>> - The token was set to the uid, PAGs were not used.
>> This worked actually wery well.
>> Anyway, we have just tried to do the same again, but this time it do not
>> work at all.
>> Some debugging shows that a token is created to the uid, and su:ing to that
>> uid works, but smbd gets permission denied.
>> strace of smbd shows this:
>> setregid(4294967295, 513)               = 0
>> getegid()                               = 513
>> setreuid(4294967295, 14431)             = 0
> That's the key line here, the real uid is left unchanged and the
> effective uid is set.  But OpenAFS relies on the real uid to set and
> retrieve tokens, so this won't work. On the OpenAFS side this was
> inadvertently changed in 1.6.0 and 1.6.1 but restored in 1.6.2.  On
> the samba side it looks like it should be setting both the effective
> and real uids with setresuid() (some code there was added specifically
> because of OpenAFS), but that code is conditional to some configure
> tests, and there's a fallback to a setuid(-1, uid) that looks like the
> one above, in case of error.  Do you see a failing setresuid() in the
> trace before the setreuid call?
Interesting, this sounds like you found the cause!

Hm, no setresuid() call before.  Actually nothing related to setting uid.
But using setuid() would prevent samba from changing users in the same
connection, won't it?

-- Ragge