On Wed, 2017-06-21 at 09:33 +0200, Jakub Hrozek wrote: > On Wed, Jun 21, 2017 at 09:01:04AM +0200, Pavel Cahyna wrote: > > On Tue, Jun 20, 2017 at 08:45:48PM +0200, Jakub Hrozek wrote: > > > Well, UID of the peer accessing the socket is the access control > > > key right > > > now. Unlike Heimdal's KCM, root doesn't have any special powers > > > (with > > > Heimdal's KCM, root can list any ccache, with our implementation, > > > only > > > that of UID 0). > > > > How will rpc.gssd retrieve users' tickets then? > > Maybe I misspoke -- root can be configured to list any user's ccache, > e.g: > KRB5CCNAME=KCM:123 klist > although I wanted to disable this by default. I admit I didn't think > about NFS. Does rpc.gssd still need to access any user's ccache even > in > the age of gssproxy? Well gssproxy will do it on behalf of rpc.gssd in any case, so either rpc.gssd or gssproxy need that. That said rpc.gssd does not access the ccaches as root, but changes the thread uid to act as the user. So when the socket is opened you should see a correct peer uid, unless libkrb5 keeps a connection open and does not drop it if the uid changes. In that case we should open a bug against libkrb5 and fix it there. Simo. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
