windows maintains a link to that share, even when the user logs out

[Andy Bakun]

Microsoft engineers are completely bogus if they can't reproduce this.  I was
working on a patch to samba to work around this by having smbd exit when it
received a LOGOFF event... but this doesn't work because WinNT clients send
the LOGOFF event and THEN update the profile, so I could get smbd to exit, but
the client immediately reconnects to update the profile, and then sometimes
the LOGOFF event is sent again after the profile is updated, and sometimes
it's not, so not only should you not try to work around this, but it is
completely impossible to do so.  If microsoft engineers can't reproduce this,
then they can come and check out my network, because it happens consistantly
AT EVERY LOGOFF!  It should be as easy as changing:

- send logoff event
- update profile

to

- update profile
- send logoff event

but apparently finding this in the NT source code is beyond the ability of the
MS programmers.

Anyway, I had also tried changing the deadtime value if a share designated as
'the profile share' was the only one open and a logoff event was received, so
smbd would exit at the right time, but that wasn't reliable either.

I seriously doubt MS is going to fix this.

End of rant.

Andy.

Luke Kenneth Casson Leighton wrote:

> > > Two points:
> > >
> > > 1. The FAQ's warn about using the easy way out (the /home share) since
> > > windows maintains a link to that share, even when the user logs out.
>
> this is a serious bug in windows (95 and nt) that microsoft has not
> been able to reproduce or fix yet (it's been there for years), see
> NTBUGTRAQ archives on NetWkstaUsers bug.
>
> because the connection is still open, the browsing is done on this share.
> because this share was opened by the previous user, the browsing is done
> as the previously logged in user.
>
> this is not good.
>
> combine this with the other point: if you do not allow r-x permissions to
> absolutely everybody then profiles will not work properly, because windows
> cannot see the profile path components [as the incorrcet user].
>
> the solution is to have microsoft fix the damn problem, not compromise
> your unix security.
>
> luke