CVS update: samba/source/rpc_server

Andrew Bartlett abartlet at pcug.org.au
Fri Nov 9 16:31:10 GMT 2001


(moved over to samba-technical)

"Gerald (Jerry) Carter" wrote:
> 
> On Fri, 9 Nov 2001 abartlet at samba.org wrote:
> 
> > This change updates lp_guestaccount() to be a *global* paramater,
> > rather than per-share.  I beleive that almost all the things that this
> > could have done on a per-share basis can be done with other tools,
> > like 'force user'.
> 
> I don't think force user will do the job.  a per service guest account
> would allow for things like "allow authenticated users normal access,
> but guest connections should be done as this account)."

I do realise this.  I'm trying to reduce the code paths here - I intend
to kill the vuid and force code from authorise_login.

There is a good reason to this, because of the exact problem you mention
here.  What happens if you have a guest share accessed from Terminal
Server?

(By Terminal Server I refer to any client that opens multiple vuids over
the same TCP/IP connection).

To start with we don't check that you are indeed an authenticated user
for non-guest shares (if a non-guest established the connection), and
I'm not convinced the separate guest accounts per-share worked at all. 
At least I can't see how they work outside:
 - security = share
 - guest only = yes.

Worse still, I think you would start as one uid (during the
make_connection()) but become another on the next packet.  If we fix
this one, then we are back to 'force user = ' for a Terminal Server
case.

I intend to overhaul the connection making and checking code shortly -
and having only two possible situations makes things easier:

The two cases are:
 - normal vuid based connection.
   This needs to be simple and fast.  This is the default, and is a
particular concern because it covers the quick connections (browsing
etc) - where the setup cost is a large part of the overall time.

   This code should be fully multi-user, there should be no reason to
make assumptions about single vuids or the like.  All decisions are
based on the presented vuid alone.

 - force user/force group
   This code is more complex, and optional inherently single-user.  It
can be locked to a particular vuid for things like admin user =.   Guest
only will become a special form of 'force user/force group' inside the
code.

Once this is done the access controls well be moved into a separate
function, called both from the make_connection() and from the
change_to_user() that will do a full check the first time a vuid shows
up on a connection - not just if it issued the tcon.

By this point it should be clearer why keeping the 'have vuid' case
should be kept simple - particularly given the security issues with the
current code.  (Users of NT4 terminal server are advised to always use
the registry hack to permit multiple connections to samba, for both
performance and security reasons).

> > Almost all the user's of this paramater used it as a global anyway...
> 
> I dunno about this one.  Did you poll samba at samba.org?

By users I was referring to code, not people.  While the original user
(in authorise_login) supplies the snum parameter, the function is used
in another 4 or so places with just -1.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Samba Team member, Build Farm maintainer        abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net




More information about the samba-technical mailing list