More info on the new problem

[Jeremy Allison]

Andrew Perrin - Demography wrote:
> 
> 
> 3.) This behavior is relatively short-lived -- I tested it by logging off
> the PC as one user, waiting approximately 3 minutes, and logging back in
> as a different user -- the problem goes away and the login works fine.
> Seems like somebody's holding some information just a tad too long?
> 

Aha - *now* it's beginning to make sense.

The issue is that, like the special [homes]
share, a share that maps dynamically to a
differnt path confuses the *hell* out of NT
sometimes.

The reason follows :

NT validates each user, by doing a session_setup_and_X
call, and gets what Samba calls a vuid (valid user id)
token back for that user.

The user then maps a share, [profiles], say, using the
vuid from the logged in user. The vuid tells the server
who is creating the mapping to this share. This mapping
of a share returns a tcon value (tree connect id) that is
valid for that share.

The kicker is that the tcon id is valid *for any vuid* !

So, user A logs off, but NT being all multi-threaded like,
doesn't disconnect the tcon for the [profiles] share immediately
(it's busy doing something like flushing it's disk buffers or
whatever). User B then logs on and of course needs a 
connection to the [profiles] share. But NT thinks "hang
on, I've allready *got* a valid tcon value for the
[profiles] share, I'll just validate the user with a
session_setup_and_X and start using the old tcon
with the new vuid."

The result is as you have observed.

The problem is that Samba is expanding the share
path at *connection time*, not at access time.

This means that for a share containing a %U
expansion, so long as a tcon is valid Samba
will always refer to the disk area using the
%U expansion of the user who originally mapped
the share, not neccesarily the user who is
now using the share.

The correct fix for this is for shares that
contain user variable 'meta' expansions (ie.
anything containing a %U or %G) need to be
flagged specially in the connection struct,
and the pathname re-validated when a vuid that
is not the same as the last vuid that accessed
the share uses the path.

This is a fix Andrew and I discussed 6 months
or so ago, but we haven't got round to adding
yet.

This is slower than what we have now, as the
expensive expansion of home directory paths
is done more often than on the initial connect
(as it is now), but for a single user NT system
caching the vuid of last user and only revalidating
if this changes is probably a good enough fix.

I'll look again at the work needed to implement
this.

In the mean time, the fix would be to change
the profile path for each user to be something
like

\\samba-server\profiles\user_name\profile

where the definition of the [profiles] share
on the Samba server is :

[profiles]
   path = /home

Where /home is the directory containing all
the users home directories.

Cheers,


	Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------