# Re: \[RFC 1/1\] destroy\_creds.2: new page documenting destroy\_creds()

- From: NeilBrown \<hidden\>
- Date: 2017-08-11 07:17:45 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2017/08/125332
- Thread: https://ratatoskr.run/linux-fsdevel/2017/08/125185/t.md

```text
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.

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.  Hunting out all the places that a key might be cached, and
invalidating them, seems to deviate from the model.  If you are concerned
about leaving credentials around where they can theoretically be
misused, then set a smaller expiry time.

What is the threat-model that this change is supposed to guard against?

Looking that the syscall itself:
 1/ why restrict the call to directories only?
 2/ Every new syscall should have a 'flags' argument, because you never
    know when you'll need one.

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 [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
```

## Attachments

- [signature.asc](https://ratatoskr.run/linux-api/2017/08/125332/attachment/0) (application/pgp-signature, 832 bytes)