CVS update: samba/source/rpc_server

Andrew Bartlett abartlet at
Sat Nov 10 02:59:02 GMT 2001

Jeremy Allison wrote:
> On Sat, Nov 10, 2001 at 02:05:18PM +1100, Andrew Bartlett wrote:
> > Note:  We do this already.  We already have the vuid cache, but I've
> > never seen it cleaned.  As to read and read-write, I can see that
> > getting a little messier.
> Yes I know, it should be cleared. We actually need 3 caches,
> read-only, read-write and no access.

Could sombody manipulate the client such that they get the vuid that
sombody else had?  (and therfore abuse our vuid cache?).  In any case I
agree we need 3 caches.

> > Instead, create a separate structure (a sec_ctx_id for arguments sake)
> > and just use the vuid to look that sec_ctx_id up.
> That's what the 'user_struct' returned by the get_valid_user()
> function was meant to be.

But we need somthing that can be modified for the various force
user/force guest/admin user etc.  This is the extra flexability we have
over NT, but also the extra complexity we must deal with becouse of it.  

In any case, I'm looking at merging the auth subsystem's server_info
with the user_struct.  In particular I'm going to use this for the
password change code, which is soon to appear on my hit-list. 
> > So when a packet comes in, we do a conn & vuid lookup.  This gives us a
> > pointer (or an id for lookup) to the security context to use, without
> > further recalculation.  This would need a binary tree I think.  If this
> > is done right, you could have one 'admin user = ' on a tid while another
> > 'normal user' without interference. Hmm...
> I don't think we can do this, as we need to know if a vuid has any of the
> above (read/read-write/none) access on a conn. And we need to
> look this up on a SMB request basis.

Ahh yes, my sketched up design just denined connections with privilages
incompatible with the current connection state (ie read-only on a
read-write connection).  So yes, we probably need to do this at the
individual request level.

But nothing stops us *calculating* the information at the
change_to_user() level.

> I do have an internal design for this as an extension of the
> current vuid system. Unfortunately it's in my head right now.
> You're definately thinking along the right lines.

That is always pleasing to hear.  Maybe we can work togeather on it. 
I'll keep making some small moves to cleaning up the code in this area
to make the next step a bit simpiler.

> BTW: I just wanted to say thanks for the auth re-write you've
> done so far. When I was fixing the extra SID group bugs in 2.2
> and HEAD it was *so much* easier to do correctly in HEAD as all
> the correct information was already being passed around in the
> structures you were using. Very impressive bit of design, thanks !
> Jeremy.

Thanks!  I always pride myself on my work, and I really appriciate the
feedback - it is one of the things that keeps me going.  

Andrew Bartlett

Andrew Bartlett                                 abartlet at
Samba Team member, Build Farm maintainer        abartlet at
Student Network Administrator, Hawker College   abartlet at

More information about the samba-technical mailing list