CVS update: samba/source/rpc_server

Andrew Bartlett abartlet at
Fri Nov 9 19:06:03 GMT 2001

Jeremy Allison wrote:
> On Sat, Nov 10, 2001 at 12:38:02PM +1100, Andrew Bartlett wrote:
> > Is the redesign that significant?  I was looking at the problem and I
> > don't think its that hard:
> >
> > Basically we already have the concept of a per-connection vuid cache,
> > and we already correctly move between security contexts.  All I am
> > suggesting is moving the code around a bit, move the access control
> > stuff into the user_ok() code and make the user_ok() code understand
> > guest users.  The code should also take into account a conn->vuid_locked
> > property - which can specify that this connection is special (admin user
> > = and friends) and only allow that vuid to connect.
> >
> > Then just call user_ok() (or a much better named derivative) in
> > make_connection() *and* in change_to_user() where we already do it.
> It requires "validated vuid" caches in a connection struct (one
> for read-only, one for read-write), so we don't have to do the
> checks in the tdb on every packet. This then means that all the
> caches must be cleaned when a vuid is deleted. It's not too bad,
> but doing it *efficiently* takes some thought.

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.

This is where my next idea comes in:

Don't use the vuid

Instead, create a separate structure (a sec_ctx_id for arguments sake)
and just use the vuid to look that sec_ctx_id up.  

This has many practical advantages - in particular it allows us to deal
with authenticated pipes in the same way as we do connections at
present.  Currently if you do some things (set security descriptors for
example) over an authenticated pipe, the authenticated part of this is
ignored.  Also, the way we become and unbecome an authenticate pipe user
is just UGLY.  

This allows us to have a cache of authenticated sec_ctx_ids, without the
worry that they need to be cleaned, because we control them.  Similarly,
because its a number we control, we can use it as an array index and the
like, without security worries.

(We probably should clean them anyway, lest we leak memory, but we can
do it at our leisure if its not a vuid)

Likewise, when a particular security context is forced (as in admin user
= , security = share) we can simply attach the full security context (or
id lookup to it) to the conn, it need not be recalculated on each

Where the security context is not fixed, but is still modified (force
user/force group but not both) we simply create a new context, and store

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

Where the lookup fails, we do the 'first use' calculation, and store
either a pointer to the sec_ctx_id attached to their vuid (the most
common case by far) or a pointer to the new context created for that

The current 'register_vuid' would change, it would no longer return a
vuid, but an internal security context id.  This could be attached to
either an authenticated pipe or passed to a new register_vuid which
would store it and hand back the vuid.

This would give us full session semantics on share level security and on
authenticated pipes.

> I went through this with tridge a month or two ago (I knew this
> wasn't perfect when the code went in). Unfortunately you can't
> do it in change_user() as you don't know the intent of the
> request (read-only or read-write) at this point. Hmmmm. Maybe
> we could add that....

That does sound messy.  Doable but certainly a little messy.
> It's a bit fiddly. You're on the right lines but it's a bit
> more complex than you have listed here I think.

I suspected so, hence why I never got it finished....

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