[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-337-g73e9693

[boyang]

Jeremy Allison wrote:
> On Wed, Jul 15, 2009 at 01:35:44AM +0800, boyang wrote:
>   
>> Jeremy Allison wrote:
>>     
>>> On Tue, Jul 14, 2009 at 12:09:34PM -0500, Bo Yang wrote:
>>>
>>>   
>>>       
>>>> commit 9ef6af73b319048fc6f3891573f0e10066dffee6
>>>> Author: Bo Yang <boyang at samba.org>
>>>> Date:   Wed Jul 15 15:34:10 2009 +0800
>>>>
>>>>     s3: Make smbd aware of permission change of usershare. Since usershare are relatively volatile and non-previledge users must disconnect from smbd and reconnect to it to make share permission in effect.
>>>>     
>>>>         
>>> Hi Bo,
>>>
>>> 	This looks like a fairly invasive
>>> change we need to look at closely. Can you
>>> post an explaination of what the code is
>>> doing here please ?
>>>   
>>>       
>> When a tconx connect to a usershare, child smbd watch on directory
>> lp_usershare_path() for any changes that might affect the share's
>> permission. If a usershare is not connected, there is no need to watch
>> it.  when the share's permission is changed, including deleted(by
>> command net usershare xxxx), a event is generated by inotify and a flag
>> in conn structure is set. Then we force recheck the permission to figure
>> out if connected user can read/write it.
>>
>> It is used to dynamically check the permission change for a connection,
>> but without endless polling. The share permission is check only when
>> lp_usershare_path() is changed.
>>
>> Is there any better way to do it?
>>     
>
> Ok, I think I have thought of a cleaner way to do this.
>
> We add a new message that smbd processes, REEVALUATE_SHARE,
> which gives the share name.
>
> On receipt of this message an smbd re-reads the share
> definition to get the new acl, then walks it's connection
> lists, and the file pointer lists and makes changes where
> needed (disconnection, modification of the conn->read_only
> field, modification of the fsp->can_write field).
>
> This will work for registry shares, where modification
> can only be done via tools connected to smbd (which can
> become_root() to send the message).
>
> For usershares, we modify the "net usershare" command to
> force an update in the timestamp of the containing directory
> (cerate and delete a dummy file for example, or maybe just
> changing the st_mode on the existing usershare file would
> do). Then smbd's notice this change by having the usershare
> directory added to the list of files whose timestamps we
> watch in lp_file_list_changed().
>
> Boyang, will this work for you ? Can you see any issues
> with this idea ?
>   
To make sure I understand it correctly.
for registry:
sending msg REEVALUATE_SHARE to all child smbd with usershare names
after update the registry. smbd  walks on its connection list to see if
any client connected to the affected share. If there is not, we
finished. If there is, reload the share and walk on vuid_cache to hack
cache entry to reflect the permission changes(ent->read_only). several
cases here:
1. share is deleted, just free the serviceptr corresponding to the share
and release the connection
2. share still exists:
     a). some users in vuid_cache has no access, remove this vuid cache
entry?
     b). for users still access, just hack cache entry and reset read_only.

     Only set conn->read_only won't work, it will be overwrite by vuid
cache entry if already connected.
     Not sure about whether to hack fsp->can_write, I didn't do that,
but it worked. So I guess fsp->can_write might be overwrite by
!conn->read_only. need to make sure it.

For usershares:
     It basically is a poll method. There must be some sensible delay
between change and permission take effect...... If we ignore the delay,
everything must work like registry share. changed ---> walk on
connection and reload(if needed, otherwise done) ---> hack vuid_cache
entry..

I don't understand why should we disconnect when share still exists. If
we just disconnect, we don't have to hack vuid cache and fsp any more.
:-) Disconnecting affect connections by updated share would be the
simplest way. unfortunately, it causes bad user experience. read --->
write change for example, smbd remove the affected connection(client is
not aware of this, I assume or there is some way to notify client that
we are disconnecting? always see client initiated disconnection.:-)),
next client tries to do something there is no connection, windows will
pops up dialogues....

yep.  Even the user has right to  something, smbd  tells client  machine
to  tell  user  you cannot  xxxxxxx.

am I correct?

This multiple session multiple  tconx  from  one  client  is 
annoying...... :-).  why does ms do this..??
> Jeremy.
>
>   


-- 
Bo Yang, Software Engineer, Suse Labs
GPG-key-ID   538C4C1A
Samba Team   boyang at samba.org    http://www.samba.org/
SUSE Linux   boyang at suse.de      http://www.novell.com/