Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

apologies for duplicates (first attempt bounced from the mailing lists)

On Fri, Aug 11, 2017 at 3:17 AM, NeilBrown [off-list ref] wrote:

On Wed, Aug 09 2017, Jeff Layton wrote:
....

quoted

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.

NeilBrown

quoted

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?

Ok.

quoted

--
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html