Re: [PATCH] cifs: Support for an upcall to map SID to an uid and a gid

[Andrew Bartlett <abartlet-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Sat, 2010-12-11 at 22:11 -0500, Jeff Layton wrote:
> On Sat, 11 Dec 2010 19:57:11 -0500
> Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > On Sat, Dec 11, 2010 at 7:30 PM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> 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. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]