I've asked Markus our Kerberos developer; On 1/11/2015 6:24 a.m., Markus Moeller wrote: > Hi Amos, > > I looked at the patch and it seems fine. The user just has to know > when to renew the cache. > > Markus >
I still think we should have a separate auth-no-keytab flag though. Besides the reasons I outlined earlier (below) it can be used to document on squid.conf the conditions of use for the flag separate from NEGOTIATE as a whole. Can we have an updated patch to audit please? Amos On 23/10/2015 4:22 a.m., Amos Jeffries wrote: > On 23/10/2015 3:59 a.m., aymericvincent wrote: >> >> Hi, >> >> "Amos Jeffries" writes: >> >>> This patch appears to make Squid ignore loading keytabs entirely and >>> just allow random credentials from unspecified location(s) to be used. >> >> That's correct and that's the whole point of the diff. ("unspecified >> location"... to squid) >> >>> In the absence of a location from which to load the credentials where >>> does GSSAPI load the credentials from? >> >> When a user is logged in and authenticated to a kdc, a credentials cache is >> kept around (in practice in a file belonging to the user in /tmp on Unix) >> and used whenever kerberos authentication is required by a client. That's >> what you see when you type "klist" for example. Given that one of the >> interesting features of kerberos is single sign on, I would be surprised >> that the behaviour is not very similar on other OSes/implementations. >> >>> Is the users generic cache backed by a keytab somewhere in the local >>> account? and why can't we just load that? >> >> I'm not familiar enough with kerberos to be authoritative, but I'm quite >> sure it's not the case : the ticket granting ticket is provided in exchange >> for the user's password, not thanks to a user-specific keytab AFAIK. >> >>> Overall this seems to me to be making Squid pick a random user account >>> from the machine and sending a lot of traffic through some peer >>> pretending to be that user instead of a proxy. That is bad security, and >>> Kerberos is supposed to be the most secure authentication possible. So I >>> am not happy with this (yet). >> >> I'm fine with your opinion, but you should replace "a random user account" >> by "the account which started squid". > > I'm not sure even that is true. Because Squid dynamically alters its > user account for the workers. They may be running as some other > effective user with a different credentials cache. > > Which reminds me that Squid usually cannot be started by a non-root user > anyway. There are root privileges required to do effective-user changes, > capabilities assignment, access kernel NAT tables and some other socket > operations we do. > >> >>> NP: don't worry about small diff. We are in feature freeze for Squid-4 >>> beta cycle. Since this is a small UI change it will be held anyway until >>> Squid-5 branching, which is likely to be a month or two away. >> >> OK, I'll keep that in mind. So we can devise a better way of specifying the >> option. Moreover, I also realised that keeping the ability to specify a >> principal name in the NOKEYTAB case is pointless (and will be ignored by the >> current code) so if others prefer to keep a similar syntax (I'm not fond of >> it either), it could be login=NEGOTIATE:NOKEYTAB directly and not >> login=NEGOTIATE::NOKEYTAB. >> > > "login=NEGOTIATE auth-no-keytab" should do. > > Like I mentioned that allows a simple boolean flag in the CachePeer. > Which avoids the macro define. And also adjusting the if conditions in > all the places auth type is detected by those nasty strcmp/strncmp tests. > > Amos > _______________________________________________ > squid-dev mailing list > squid-dev@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-dev > _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev