On Sun, 12 Dec 2010 14:48:04 +1100 Andrew Bartlett <abartlet@xxxxxxxxx> wrote: > On Sat, 2010-12-11 at 22:11 -0500, Jeff Layton wrote: > > On Sat, 11 Dec 2010 19:57:11 -0500 > > Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote: > > > > > On Sat, Dec 11, 2010 at 7:30 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > > >> > > > >> Will look into this. One thing that concerns me is if a cached etnry > > > >> for a SID with its name and an id (either an uid or a gid), if that SID > > > >> now represents a different object and has differernt name, would > > > >> not cached info be incorrect? Not sure if this can ever happen > > > >> or how would it happen and if it does, what would be a trigger > > > >> for a cache revalidation and purges! > > > >> > > > > > > > > Sure, mappings can change. But, you still have the same problem with > > > > what you're proposing in these patches. The userspace program isn't > > > > setting a timeout on the key. Once a mapping is put in the keyring, > > > > it's there until it's revoked. You probably want to set a max TTL for > > > > the entries in the cache regardless of what scheme is used. > > > > > > I was under the impression that SIDs are never reused. Perhaps I am mistaken. > > > > > > > That may be, but the mapping of a SID is dependent upon settings in > > config files that could change. It seems reasonable to me to only cache > > these mappings for a period of time in the event that they do. That > > period of time could default to being rather long and be tunable. > > I think that instead some explicit signal should be made to indicate > that a mapping has changed, so you don't have to worry about cache > times. It should change *very* rarely and only on specific > administrator intervention. We do a lot of things to avoid this > happening in the normal course of events. > What would provide this signal? winbindd? I suppose we could add a knob or something under /sys that tells cifs to dump the idmap cache. We would also have to consider however how to deal with someone running an old winbindd that doesn't signal the kernel properly. -- Jeff Layton <jlayton@xxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
