On Wed, Jun 21, 2017 at 09:33:26AM +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? I must admit I am new to the age of gssproxy, so I don't know. Does the kernel already support gssproxy as a replacement for rpc.gssd? Even if it does, doesn't it just shift the question from rpc.gssd to gssproxy, i.e. "How will gssproxy retrieve users' tickets then?"? (Actually IIUC gssproxy is used for more than NFS, so the question becomes even more important.) OTOH https://pagure.io/gssproxy/blob/master/f/proxy/docs/NFS.md says: "we assume a modern version of rpc.gssd which drops privileges to the requesting uid before calling GSSAPI." If rpc.gssd does that (I don't see it documented in the manual page), it probably should just work. Nevertheless, the question about gssproxy remains valid. P. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
