[PATCH/RFC] s3:smbd: reload services upon tree connect

[Brian Campbell]

On Sat, Oct 27, 2012 at 6:58 AM, Andreas Schneider <asn at samba.org> wrote:
> On Wednesday 24 October 2012 12:56:50 Brian Campbell wrote:
>> Hey, just wondering if anyone's had a chance to look at this yet. I
>> had a chat on IRC with obnox yesterday
>
> I think it shouldn't be always reloaded. I think we shold only reload if the
> connecting user is different to the current user. However I haven't tested it.
>
>         if (get_current_vuid(conn) != vuid) {
>             reload_services(sconn, conn_snum_used, true);
>         }

I think that this will always be trivially true. get_current_vuid()
just returns current_user.vuid. switch_messages() calls
change_to_root_user() for messages which don't have AS_USER set, which
is true of the tcon and tcon_and_X messages. change_to_root_user()
sets current_user.vuid to UID_FIELD_INVALID. So, when
make_connection() is called from one of reply_tcon() or
reply_tcon_and_X(), get_current_vuid() will never match vuid.

Beyond that, I think that we should always call reload_services() upon
tree connect, not just if the user has changed from the last connect.
We store the global and service settings globally for the process, but
the way the settings files are parsed, the includes can depend on
variables like %U and %L that can vary between different tree connects
over the same connection. In order to ensure that those are correct at
the time of the tree connect, we need to reload the services with the
appropriate expansions in place.

As I mentioned, I believe this may help with bug 5151
(https://bugzilla.samba.org/show_bug.cgi?id=5151), in which cifs on
Linux uses the same connection for connecting to services using
different NetBIOS names on the same machine. Because we aren't
reloading services when the second tree connect happens, we never
expand the includes with the second server NetBIOS name, and you don't
get the appropriate service definition. In this instance, the vuid
isn't necessarily changing, but we still want to reload the service
definitions. I think that adding the reload is necessary, but not
necessarily sufficient, to fix bug 5151; I know that we are setting up
the user substitutions like %U in switch_message() when we call
set_current_user_info(), but I don't know if there's anywhere that we
set the %L substitution properly.

A further effect of adding the reload here unconditionally is that if
the config files are updated between tree connects, new ones will get
the updated configuration. While you can call smbcontrol all
reload-config to force this manually when you make changes, it is more
convenient if changes take effect as of the next tree connect, rather
than manually calling reload-config or disconnecting all mounts in
order to kill the connection and start a new one.

>> It also says that if I don't get him to assign me individual
>> copyright, then we can still do it with the copyright held by the
>> corporation with a simple set up process. I'm assuming that the
>> developer's certificate of origin below is that simple set-up process.
>> Does that mean that this developer's certificate of origin is not
>> required if I hold individual copyright? Or is it required for both
>> cases, individual or corporate ownership? Is there any difference in
>> how I should send it in in either case, such as my personal vs. work
>> email address?
>
> If you contribute code under your own personal copyright then everything is
> fine.
>
> If you're company doesn't allow that you need to sign the Certificate of
> Origin.

Thanks. Sent that in. If this patch is applied, please add:

Signed-off-by: Brian Campbell <brian.campbell at editshare.com>

-- Brian