> On Aug 11, 2017, at 3:17 AM, NeilBrown <neilb@xxxxxxxx> wrote: > > On Wed, Aug 09 2017, Jeff Layton wrote: > .... >> >> Thanks, that helps a bit. I'm less clear on what the higher-level >> vision is here though: >> >> Are we all going to be running scripts on logout that scrape >> /proc/mounts and run fslogout on each? Will this be added to kdestroy? >> >> Or are you aiming to have KCM do this on some trigger? (see: >> https://fedoraproject.org/wiki/Changes/KerberosKCMCache) >> >> Also, doing this per-mount seems wrong to me. Shouldn't this be done on >> a per-net-namespace basis or maybe even globally? > > Having looked at the code, I think this is invalidating cached > credentials globally -- or at least, globally for all filesystems that > use sunrpc. Yes all filesystems that use sunrpc could benefit from by calling the same routine that NFS calls. It only does it per “auth” flavor. If you have multiple flavor mounts, only specified one is effected. > I actually question the premise for wanting to do this. Tickets have a > timeout and will expire. Any code that is allowed to get a ticket, can > hold on to it as long as it likes - but it will cease to work after the > expiry time. However, when kdestroy is called, then any code that tries to use it will yet. User land is unaware that the kernel has cached his credentials. > Hunting out all the places that a key might be cached, and > invalidating them, seems to deviate from the model. No caching should be valid after credentials were explicitly removed. > If you are concerned > about leaving credentials around where they can theoretically be > misused, then set a smaller expiry time. That’s correct. The only means that people who have complained about is left with is using short credentials. But security context establishment is not for-free and impacts performance. > What is the threat-model that this change is supposed to guard against? It’s a limitation of a system that I feel has solution of providing the extension to kdestroy that destroys FS creds. What’s the disadvantage of providing this feature? There are folks who have been asking for it. It tightens up the security. > Looking that the syscall itself: > 1/ why restrict the call to directories only? No real reason. It seems unlikely that the practical unlog application would open a filesystem specific file and then call the unlog on that file. It’ll be problematic as without creds no close can be done and would leave state on the server? > 2/ Every new syscall should have a 'flags' argument, because you never > know when you'll need one. Ok. > > NeilBrown > > >> >> It seems like we can afford to be rather cavalier about destroying >> creds here. Even if we purge creds for a user that should have remained >> valid, we just end up having to re-upcall for them, right? >> -- >> Jeff Layton <jlayton@xxxxxxxxxx> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
